Download Jdk1.8.0_321

0 views

Skip to first unread message

Latanya Hariri

unread,

Aug 3, 2024, 4:42:54 PM8/3/24

to forsprimulles

OK, thanks for confirming that the issue is still present with the latest jdk1.8.0_321 build.
The source of the issue seems to be some weird state of the SSLEngine (status CLOSED but handshake status NEED_WRAP). I have im proved the SNMP4J 2.8.x code to cover this case too in TLSTM.ServerThread.runDelegatedTasks. The following new if-statement ensures that the socket is registered with the outQueue to write out-data:

But we are seeing data recieved at socket but not processed at snmp4j many a times and hence causing SNMP transaction timeout. We are looking into the details to share but any suggestions around this area is greatly appreciated

Hi norrisjeremy,
Thanks for pointing us to this bug. This could be the root cause, indeed. As expected my fix in the 2.8.9 SNAPSHOT did not really solve it, because then instead looping in the read key (without data coming in) it looped on the write key without having any data to send. As a result, the SSLEngine is a dead lock situation. In SNMP4J 3.6.x I closed the session and the TCP connection in this case. This could solve the issue for SNMP4J 2.x too.
Best regards,
Frank

Thanks @norrisjeremy and @AGENTPP
Can you please share work around code or a snapshot jar with changes in 2.8.x for handling this until fix is released in Java 1.8 load.
This would help use test further on SNMP over TLS.

I have changed the handling of the CLOSED SSL engine status once again in the latest 2.8.9 SNAPSHOT. Now the underlying TCP connection will be closed in any case to fully reset the connection.
Maybe that helps.
Of course, you can try newer JDKs too. The SSL engine was improved a lot from 8 to 17 - I am not sure if everything has been back ported to 8.

Hi @AGENTPP
We are communicating with Oracle to get the fix backported but we are unsure of the rootcause.
This issue was in JKS keystore and occationally seen.
In BCFKS keystore we are frequently seeing this issue when we are establishing connection itself. Took the thread dump and noticed a dead lock.

This seems to be a bug. Currently unclear why it does not occur on SNMP4J 3.x too, but that might be related to using not Hashtable but a Collections.synchronizedMap there for Snmp.pendingRequests.
I am going to provide a fix ASAP.

I was just guessing that the JDK bug is related to the issue you observe. I have no proof for that, except that this behavior was not observed with recent JDKs and closing connections is part of your issue.
Does not SNMP4J 2.8.9 fix your problem? It has been released today.

Can you please share some pointers as how we can debug the issue on snmp4j side. As I had requested, how can we decrypt SNMP over TLS data? This might help us understand the cause. We have tried TLS decryption and was successful for HTTP over TLS but not SNMP. In your tests, how are you decrypting data for tests? Is there any other memory analyser tools or code used for decryption?

Maybe you can send a larger debug log-file with the full communication starting from the connect to the Key is Writable loop to the AGENTPP support email address. Maybe we do not have identified the root cause in your case yet.

I installed Talend Open Studio for Data Integration 8.0.1. Initially, I had java version 8 of JRE installed and I was getting the error message that 'version 1.8.0_321 of the JVM is not suitable for this product. Version: 11 or greater is required'. So I installed java version 11 of jdk and now I get the error message 'Java Runtime Environment (JRE) or Java Development Kit (JDK) must be available in order to run TOS_DI-win-x86_64. No Java virtual machine was found after searching the following locations: C:\Program Files\Java\jre1.8.0_321\bin'.

After changing the PATH and HOME and the TOS ini file, I was still getting the error. I found that I could launch TOS directly from the directory, but get the error launching from the shortcut. Found out the shortcut set up by the install includes the Java path in the Target: "C:\Program Files (x86)\TOS_DI-8.0.1\studio\TOS_DI-win-x86_64.exe" -vm "C:\Program Files\Java\jdk1.8.0_321\bin".