[Bug]: Cached Modbus TCP hiccup when another connection is established

[JoelGaechter]

What happened?

I recently updated from version 0.13.0 to 0.13.1, and encountered an issue where my device would time out when another device establishes a connection.
My setup consists of four devices connected through Modbus TCP, whereas three of them are turned on by the other one. A single CachedPlcConectionManager is used for all connections and each one has a read-write loop running in a separate thread. If an exception occurs in the loop, the connection is removed from the cache using CachedPlcConnectionManager::removeCachedConnection.
Initially, the loop would only succeed for one device until this switches on the others. Previously the others would also start communicating seamlessly, but now the former has a hiccup at this point, which in my case causes it to timeout and switch off the others again.

In my understanding the connections should be decoupled and not influence each other. Was there anything introduced that could cause the connections to interfere with each other during reading, writing, or connecting

Version

v0.13.1

Programming Languages

• plc4c
• plc4go
• plc4j
• plc4net
• plc4py

Protocols

• AB-Ethernet
• ADS /AMS
• BACnet/IP
• C-Bus
• CANopen
• EtherNet/IP
• Firmata
• IEC-69870
• KNXnet/IP
• Modbus
• OPC-UA
• Profinet
• S7
• S7-light

[chrisdutz]

Hi Joel,
Admittedly I don't instantly recall any changes in the modbus driver that should result in such a behavior.
However, I am currently in the process of completely rewriting the core of PLC4J and along those lines, also updating the scraper and the connection-cache as well as updating all existing Java drivers.

I would therefore like to ask you to be a bit patient. Unfortunately my time-frame is something round half a year.

If you do need something quickly, I would be willing to have a look, but that would need to be a paid contract. Or you beat me to is or find someone who's going to have a look for you.

Chris

[JoelGaechter]

Hi Chris,
Thanks for the heads up. For me that's okay, as I can continue working with the previous version.
If I find the time, I will also give it a closer look myself to see whether I can pinpoint the cause more accurately.

[chrisdutz]

Thanks :-)
And the more information you have, the quicker things are usually fixed ... best option would be, that you even find the fix and submit a PR ... If you want to head down that road, I will always take time to help mentor you, if you need me (Exclusion of this is the following 10 days, as I'll be without reception for that time)
Chris

[yancyang1989-gif]

I controlled the process by locking the same PLC address; you can try it to see if it works.

public static T withPlcConnection(String address, PlcConnectionFunction<PlcConnection, T> operation) {
ReentrantLock lock = locks.computeIfAbsent(address, k -> new ReentrantLock());
lock.lock();
try {
try (PlcConnection plcConnection = getConnection(address)) {
return operation.apply(plcConnection);
} catch (Throwable e) {
plcConnectionManager.removeCachedConnection(address);
throw new RuntimeException("Failed to get PLC connection for address: " + address, e);
}
} finally {
lock.unlock();
}
}