Chapter 6. Known issues

6.1. KubernetesServiceImporter() cannot be directly registered in Eclipse Vert.x Reactive Extensions (Rx)

Description
You cannot directly register KubernetesServiceImporter() with the Reactive Extensions (Rx) for Eclipse Vert.x.
Cause
Service importers do not have a generated RxJava 2 implementation.
Workaround
You must create an instance of KubernetesServiceImporter and encapsulate it with {@link io.vertx.reactivex.servicediscovery.spi.ServiceImporter} as shown in the following example: 
{@link examples.RxServiceDiscoveryExamples#register(io.vertx.reactivex.servicediscovery.ServiceDiscovery)}

The following example shows how to register KubernetesServiceImporter() in Eclipse Vert.x Reactive Extensions (Rx). 

ServiceDiscovery discovery = ServiceDiscovery.create(vertx);
discovery.getDelegate().registerServiceImporter(new KubernetesServiceImporter(), new JsonObject());

6.2. Red Hat AMQ Streams images are not available for IBM Z and IBM Power Systems

The Red Hat AMQ Streams Operator and Kafka images are not available for IBM Z and IBM Power Systems. Since the images are not available, the vertx-kafka-client module is not certified to work with AMQ Streams on IBM Z and IBM Power Systems.

6.3. Connection between a RHEL 8-based database application and a RHEL 7-based MySQL 5.7 database fails due to TLS protocol version mismatch

Description

Attempting to open a TLS-secured connection using OpenSSL between an application container built on a RHEL 8-based OpenJDK builder image and a database container built on a RHEL 7-based MySQL 5.7 container image results in a connection failure due to a javax.net.ssl.SSLHandshakeException at runtime: For more detail, view the issue in JIRA. 

...
Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
...

Cause

The issue occurs due to a difference in the latest supported TLS protocol version between RHEL 7 and RHEL 8. The TLS implementation on RHEL 7 supports TLS protocol versions 1.0 (deprecated), 1.1, and 1.2. The TLS implementation on RHEL 8 also supports TLS protocol version 1.3, which is also the default TLS version used in RHEL 8-based builder images. This discrepancy may cause a TLS protocol version mismatch between application components while negotiating a TLS handshake, which in turn causes the connection between the application and database containers to fail.

Workaround

To prevent the issue described above, manually specify a TLS protocol version that is supported on both operating system versions in your database connection string. For example: 

jdbc:mysql://testdb-mysql:3306/testdb?enabledTLSProtocols=TLSv1.2

6.4. False Connection reset by peer error messages when calling application endpoint

Making an HTTP request on an endpoint of an Eclipse Vert.x application using either the curl tool or a Java HTTP client, produces the following error in the logs after each request: 

io.vertx.core.net.impl.ConnectionBase
SEVERE: java.io.IOException: Connection reset by peer

This behavior is caused by the interaction of the Netty application framework and the HAProxy load-balancer used by OpenShift. The error occurs due to existing HTTP connections being re-used by HAProxy without closing. Even though the error message is logged, no error condition occurs. HTTP requests are handled correctly and the application responds as expected.