[JBoss JIRA] (WFLY-13748) "Contains non-LDH ASCII" characters during remote EJB SSL call in IPV6 network
by Flavia Rainone (Jira)
[ https://issues.redhat.com/browse/WFLY-13748?page=com.atlassian.jira.plugi... ]
Flavia Rainone commented on WFLY-13748:
---------------------------------------
[~jlecollo] Thanks for your PR! It wlil be soon reviewed and merged!
> "Contains non-LDH ASCII" characters during remote EJB SSL call in IPV6 network
> ------------------------------------------------------------------------------
>
> Key: WFLY-13748
> URL: https://issues.redhat.com/browse/WFLY-13748
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Web (Undertow)
> Affects Versions: 19.1.0.Final
> Reporter: Julien Le Colloëc
> Assignee: Flavia Rainone
> Priority: Blocker
>
> *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)
5 years, 10 months
[JBoss JIRA] (WFLY-13859) Clustering TS: Support testing against different Infinispan Server distributions
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13859?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13859:
----------------------------------
Description:
Currently, the testsuites pom.xml downloads a specific upstream version and tests against it. The goal of this Jira is to allow for testing with different distributions such as custom builds of Infinispan Server or productized builds. This probably needs to look like this, all controlled by parameters:
(1) downloading datagrid maven execution is disabled
(2) datagrid is provisioned from a local file
(3) datagrid configuration is provided from a local directory
(4) driver version is overriden by a parameter
Note that the code to run only these tests is already in place with a specific maven profile.
was:
Currently, the testsuites pom.xml downloads a specific upstream version and tests against it. The goal of this Jira is to allow for testing with different distributions such as custom builds of Infinispan Server or productized builds. This probably needs to look like this, all controlled by parameters:
(1) downloading datagrid maven execution is disabled
(2) datagrid is provisioned from a local file
(3) datagrid configuration is provided from a local directory
Note that the code to run only these tests is already in place with a specific maven profile.
> Clustering TS: Support testing against different Infinispan Server distributions
> --------------------------------------------------------------------------------
>
> Key: WFLY-13859
> URL: https://issues.redhat.com/browse/WFLY-13859
> Project: WildFly
> Issue Type: Task
> Components: Clustering, Test Suite
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
>
> Currently, the testsuites pom.xml downloads a specific upstream version and tests against it. The goal of this Jira is to allow for testing with different distributions such as custom builds of Infinispan Server or productized builds. This probably needs to look like this, all controlled by parameters:
> (1) downloading datagrid maven execution is disabled
> (2) datagrid is provisioned from a local file
> (3) datagrid configuration is provided from a local directory
> (4) driver version is overriden by a parameter
> Note that the code to run only these tests is already in place with a specific maven profile.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13859) Clustering TS: Support testing against different Infinispan Server distributions
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13859?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13859:
----------------------------------
Summary: Clustering TS: Support testing against different Infinispan Server distributions (was: Clustering TS: Support testing against different Infinispan Server distribution versions)
> Clustering TS: Support testing against different Infinispan Server distributions
> --------------------------------------------------------------------------------
>
> Key: WFLY-13859
> URL: https://issues.redhat.com/browse/WFLY-13859
> Project: WildFly
> Issue Type: Task
> Components: Clustering, Test Suite
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
>
> Currently, the testsuites pom.xml downloads a specific upstream version and tests against it. The goal of this Jira is to allow for testing with different distributions such as custom builds of Infinispan Server or productized builds. This probably needs to look like this, all controlled by parameters:
> (1) downloading datagrid maven execution is disabled
> (2) datagrid is provisioned from a local file
> (3) datagrid configuration is provided from a local directory
> Note that the code to run only these tests is already in place with a specific maven profile.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13859) Clustering TS: Support testing against different Infinispan Server distribution versions
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13859?page=com.atlassian.jira.plugi... ]
Radoslav Husar reassigned WFLY-13859:
-------------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
> Clustering TS: Support testing against different Infinispan Server distribution versions
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-13859
> URL: https://issues.redhat.com/browse/WFLY-13859
> Project: WildFly
> Issue Type: Task
> Components: Clustering, Test Suite
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
>
> Currently, the testsuites pom.xml downloads a specific upstream version and tests against it. The goal of this Jira is to allow for testing with different distributions such as custom builds of Infinispan Server or productized builds. This probably needs to look like this, all controlled by parameters:
> (1) downloading datagrid maven execution is disabled
> (2) datagrid is provisioned from a local file
> (3) datagrid configuration is provided from a local directory
> Note that the code to run only these tests is already in place with a specific maven profile.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13859) Clustering TS: Support testing against different Infinispan Server distribution versions
by Radoslav Husar (Jira)
Radoslav Husar created WFLY-13859:
-------------------------------------
Summary: Clustering TS: Support testing against different Infinispan Server distribution versions
Key: WFLY-13859
URL: https://issues.redhat.com/browse/WFLY-13859
Project: WildFly
Issue Type: Task
Components: Clustering, Test Suite
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Currently, the testsuites pom.xml downloads a specific upstream version and tests against it. The goal of this Jira is to allow for testing with different distributions such as custom builds of Infinispan Server or productized builds. This probably needs to look like this, all controlled by parameters:
(1) downloading datagrid maven execution is disabled
(2) datagrid is provisioned from a local file
(3) datagrid configuration is provided from a local directory
Note that the code to run only these tests is already in place with a specific maven profile.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months