"java.io.IOException: End of stream reading message" when connecting with v21.0.7 uc4.jar to JCP

[Michael A. Lowry]

We have several applications that use the Java Application Interface to communicate with the Automation Engine.

Following a successful upgrade of our AE systems to v21, we are in the process of updating our applications to use the new version 21 uc4.jar too. This will enable TLS-secured WebSocket connections. (See AWA v21 inter-process communication.)

I did some quick tests on my PC and was able to get it working quite quickly. I switched from the v12.3.9 uc4.jar to the v21.0.7 one, changed the port number to point to one of the new v21 JCPs, and it just worked.

However, when I try to run the same program from a Linux VM, I encounter a problem.

Connecting to Automation Engine.
AE system name    :  uc4
Hostname & port   :  uc4.mycompany.com:8443
Client number     :  1
User & department :  UC4/UC4
AE API version: 21.0.7+build.1685986413752
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at com.swissre.uc4.tools.Main.main(Main.java:37)
Caused by: java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        ...
        ... 5 more
Caused by: java.io.IOException: End of stream reading message
        at com.uc4.communication.Connection.readByteBuffer(Connection.java:1008)
        at com.uc4.communication.Connection.readMessage(Connection.java:712)
        at com.uc4.communication.Connection.<init>(Connection.java:307)
        at com.uc4.communication.Connection.loadBalancing(Connection.java:623)
        at com.uc4.communication.Connection.open(Connection.java:500)
        at com.uc4.communication.Connection.open(Connection.java:430)
        at com.uc4.communication.Connection.open(Connection.java:407)
        ...
        ... 10 more

I've seen that this exception can occur if one uses the wrong version of uc4.jar. I'm using the undocumented UCVersion class to verify the API library version.

UCVersion uc4Version = new UCVersion();
String uc4VersionString = uc4Version.VERSION;
System.out.println("AE API version: " + uc4VersionString);

As you can see in the output above, the program is definitely using v21.0.7.

I have verified that the host and port number are reachable. (Initially, the firewall was blocking the traffic, but after a new firewall rule, I can see that the connection is going through.)

I also verified that $JAVA_HOME/../lib/security/cacerts contains valid root CA certificates for the organization.

I also verified that I'm using the same JRE on the Linux VM as on my laptop (Temurin JDK 17).

Any ideas?

[Andrzej Golaszewski]

Hi Michael Lowry

I don't know if it is relevant, i checked the compatibility matrix. The Java API does not offical support Temurin JDK 17. Maybe a downgrade to latest supportet version Temurin JDK V11 can solve the problem. Try to check at start which java Version is used.

Best regards

Andrzej Golaszewski

[Michael A. Lowry]

I started out with JDK v11, and tried v17 because that's what I'm using on my laptop where it works.

[Michael A. Lowry]

On the theory that the problem might be related to SSL, I tried running the program with this JVM property set:

-Djavax.net.debug=ssl,handshake

No SSL debugging messages appeared in the console, so I don't think it's even getting to that point in the process.

[Andrzej Golaszewski]

Hi Michael.

For SSL Handshake testing i use SSLPoke.java 

java SSLPoke AE-SYSTEM <JCP-PORT>

Based on the log you submitted an example: 

java SSLPoke uc4.mycompany.com 8843

Is the Port setting correct? I remember the standard port for the jcp is 8088. 

If the small java programm can connect to the jcp, and do the ssl handshake you will get the Message 

Successfully connected

Otherwise there comes an error message. 

Best regards 

Andrzej Golaszewski

[Michael A. Lowry]

That SSLPoke.java program is very handy, thanks. Using it, I confirmed that there's no problem establishing an SSL connection between the VM and the AE server.

The exception that appears from my program looks similar to the one that appears when attempting to use the old v12.3 JAR to connect to a v21 JCP. This is described in KB article 257705. I will look into the JAR of my program to make sure it is being built with the right version of uc4.jar.

[Michael A. Lowry]

Indeed, the JAR file was still being built with the v12.3.9 APIs, even though the IDE where I was testing and building it was using the v21 APIs. I changed the build settings, and now I have a JAR that works as expected.

One thing I do not understand is why UCVersion was reporting v21 in the failure case. Perhaps this is not a reliable way to detect the version of the UC4 APIs in use.