Deadlock/hanging on JDK socket write

[benchong913]

Java Version: OpenJDK 17.0.2 2022-01-18 LTS
RabbitMQ Client Version: 4.12.0

We had a situation very similar to this problem at production.

#236

We had try to set the connectionFactory to use NIO but there are some Exception during reading frames
Such as IOException reached EOF, SSLProtocolException Input record too big
It seem not quick stable

SSLProtocolException may be the JDK problem
https://bugs.openjdk.org/browse/JDK-8227651

Do you have any suggestion like upgrade the RabbitMQ Client version to which version or keep using the NIO or else?

[michaelklishin]

Using the latest JDK and the latest RabbitMQ Java client is always recommended. 4.12.0 is from April 2020.

[benchong913]

Do you recommend to use NIO in this situation or BIO is enough?

[acogoluegnes]

I don't think NIO will help much, but it should not hurt to test. I would recommend upgrading to the latest client version though, 4.x is no longer supported. Upgrading to 5.x should be painless (see "breaking changes"), 5.16.0 is currently the latest release.

I don't know if this is related to the JDK problem you mentioned, but this problem pops up for a user once in a while (less than once a year I'd say), and we never managed to narrow it down to an actionable item to fix in the client. It seems to be related to something specific to the infrastructure, maybe OS- or network-related.

A workaround that usually works is to set up a reasonably low heartbeat value and the shutdown executor, so that the client detects fast enough the connection is dead and it does not get stuck when trying to close it, and let connection recovery kicks in:

connectionFactory.setRequestedHeartbeat(5);
ExecutorService shutdownExecutor = Executors.newSingleThreadExecutor();
connectionFactory.setShutdownExecutor(shutdownExecutor);

[benchong913]

OK. I will try it.

Thanks a lot