-
|
I am connecting to multiple S7-300 PLCs and reading tags every second. However, last day i encountered below problem while connecting to one of the PLCs. I am setting up connections all together at the @PostConstruct of my application and this prevented my application from resuming the rest of the execution (reading of tags). As shown by the logs the connection is not established, but it is not rejected either or timed out. The retry mechanism of the driver kicks off every second and the connection resets again and i seem to be stuck in this loop with my application unable to move forward. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 6 replies
-
|
I would reccomend to not setup the connections in the PostConstruct ... otherwise, if the connection should break it would not be re-created. For scenarios such as yours, we have the ConnectionCache ... which manages the open-connections and allows re-use of connections. The benefit is: If a problem occurs and the connection breaks, the connection cache will invalidate the connection and create a new one, once it is requested. So I would suggest, you switch to using that and stop using this pre-initialized map. |
Beta Was this translation helpful? Give feedback.
-
|
That's what the connection cache does ... it keeps the session open in the background and re-uses connections. So it does exactly what you want to do. |
Beta Was this translation helpful? Give feedback.
-
|
The lease time only limits the time that a process can keep the conneciton without giving it back. |
Beta Was this translation helpful? Give feedback.
-
|
ok just wanted to understand if there was a quicker fix, as it does not seem right for the default connection manager to block waiting for a connection and not throw a PlcConnectionException if a SocketException occurs. |
Beta Was this translation helpful? Give feedback.
-
|
Well in contrast to typical connection pools, where there is a large number of connections to a device, with PLCs this is some times limited to 1-3 connections. Therefore we implemented the connection-cache in a way to reflect this. We could probably also create a connection-pool, that operates similarly to those of relational databases, however that would be a new feature. Currently if the connection is blocked, then all others requiring access to that connection need to wait. They would need to anyway as most protocols wouldn't handle concurrent requests gracefully. |
Beta Was this translation helpful? Give feedback.
-
|
I think we still need to polish PLC4X especially in some of the edge-cases where some equipment is mis-behaving. So we're happy if you are reporting stuff like this. |
Beta Was this translation helpful? Give feedback.
-
|
It is important to note that the code must "close" the connection, so the try-with-resources block is ideal. If you don't use that, be sure to call "connection.close()" at the end (ideally in a finally block) |
Beta Was this translation helpful? Give feedback.
-
|
I think I will create a new manual test utility that will in a loop collect data from my PLCs ... then I can experiment on how the systems react to device or network outages. |
Beta Was this translation helpful? Give feedback.
Well in contrast to typical connection pools, where there is a large number of connections to a device, with PLCs this is some times limited to 1-3 connections. Therefore we implemented the connection-cache in a way to reflect this. We could probably also create a connection-pool, that operates similarly to those of relational databases, however that would be a new feature.
Currently if the connection is blocked, then all others requiring access to that connection need to wait. They would need to anyway as most protocols wouldn't handle concurrent requests gracefully.