The OPCUA client driver uses the due time for publish responses (keepalive) to check if the OPCUA server is still responding. Normally if the connection to the OPCUA server is lost, the connection is closed at the TCP level. If however no publish response from the OPCUA server is received when a keepalive message is due from the OPCUA server, while the TCP connection remains alive (ACK are still sent by the remote system running the OPCUA server), the OPCUA client driver will attempt to gracefully close the connection by sending a request to the OPCUA server to delete the subscription, after a timeout sending a request to the OPCUA server to close the session and after another timeout send a request to close the secure channel. If there is still no response from the OPCUA server, the OPCUA client tries to re-establish the secure connection and at this stage waits endlessly for a confirmation from the Server.
When in the runtime values are written to variables of the OPCUA client driver or multiple variables are requested from the OPCUA client driver, while the driver is waiting for a response from the OPCUA server, the runtime stops responding as it does not receive a response from the driver that in turn waits for a response from the OPCUA server.
This specific scenario may happen in cases where an OPCUA server stops responding e.g. due to a crash or other undefined state.
The OPCUA client driver uses the due time for publish responses (keepalive) to check if the OPCUA server is still responding. Normally if the connection to the OPCUA server is lost, the connection is closed at the TCP level. If however no publish response from the OPCUA server is received when a keepalive message is due from the OPCUA server, while the TCP connection remains alive (ACK are still sent by the remote system running the OPCUA server), the OPCUA client driver will attempt to gracefully close the connection by sending a request to the OPCUA server to delete the subscription, after a timeout sending a request to the OPCUA server to close the session and after another timeout send a request to close the secure channel. If there is still no response from the OPCUA server, the OPCUA client tries to re-establish the secure connection and at this stage waits endlessly for a confirmation from the Server.
When in the runtime values are written to variables of the OPCUA client driver or multiple variables are requested from the OPCUA client driver, while the driver is waiting for a response from the OPCUA server, the runtime stops responding as it does not receive a response from the driver that in turn waits for a response from the OPCUA server.
This specific scenario may happen in cases where an OPCUA server stops responding e.g. due to a crash or other undefined state.
An issue was addressed in the OPCUA client driver where under circumstances requests from the runtime were no longer processed while waiting in a specific state for a response from an OPCUA server that had entered an invalid state.
Now the OPCUA client driver no longer attempt to gracefully close the connection when it finds that the OPCUA server is no longer responding. Instead it will immediately close the connection and set the variables to the INVALID status. The driver continues to serve requests from the rutnime and the runtime continues execution normally.