Hello,

The Bad_SubscriptionIdInvalid StatusCode is generated by the Server in response to attempting to remove MonitoredItems from the Subscription. The specification simply describes this StatusCode to mean that “The subscription id is not valid”. This could be caused by the Subscription no longer existing on the Server. Has the Server been restarted or could the Subscription have timed out before removing MonitoredItems was attempted?

Are you able to check the Server’s logs for its response to receiving a DeleteMonitoredItems request to which it responds with that StatusCode?

Also, has the Server been implemented with Prosys OPC UA SDK for Java?

Hello,

The onTimeout method of SubscriptionAliveListener is called when more time than PublishingInterval (default value 1000 ms) multiplied by MaxKeepAliveCount (default value 20) multiplied by TimeoutDetectionFactor (default value 1.3) has elapsed since last contact from the Server. Note, that if you have set PublishingInterval to, e.g. 100 ms, the Subscription would time out after 2.6 seconds of inactivity.

The onTimeout being called implies that either the Server isn’t sending new notifications or keep alive messages as often as the Client has requested and the Server has agreed to do or there is a communication error between the Client and the Server. In the latter case the onStateChange method of ServerStatusListener should have been called with ServerState CommunicationFault to indicate the error.

If either the onTimeout or the onLifetimeTimeout method has been called, it is possible that the Server has already deleted the Subscription and its MonitoredItems which would explain why Client requesting to delete MonitoredItems would cause the Bad_SubscriptionIdInvalid for a Subscription that no longer exists on the Server. If the Subscription no longer exists, you will most likely get the same StatusCode when attempting to remove the Subscription, so you can recreate the Subscription and its MonitoredItems. I would suggest to try deleting the MonitoredItems and the Subscription anyway to guarantee that they no longer exist on the Server.

Hello,

A clarification to the previous message, onTimeout means that the Subscription hasn’t send data or keep alive in the expected period of time. While that could imply that the Subscription no longer exists on the Server, it could also be caused by the Server being incapable of sending messages in the expected time frame for some other reason, e.g. connection break. onLifetimeTimeout means that the Subscription hasn’t send anything and it also should have been deleted on the Server side. In short, onTimeout implies that something might be wrong with Subscription, the Server in general or the connection between the Client and the Server and onLifetimeTimeout means that the Subscription no longer exists on the Server for certain.

Though, it is worth mentioning that at the moment of writing this there is still a mistake in the specification that says that MaxKeepAliveCount is used instead of LifetimeCount to determine when the Subscription is deleted. Later in the specification the purpose of KeepAliveCounter and LifetimeCounter of a Subscription are explained in more detail correcting the earlier mistakes. Still, there have been cases where Server’s have used MaxKeepAliveCount in place of LifetimeCount to determine when to delete a Subscription, so the Server you’re connecting to could actually delete the Subscription when onTimeout is triggered.

For more information on Subscriptions, see https://reference.opcfoundation.org/Core/Part4/5.13.1/

If you’re expecting there to be connection breaks between the Client and the Server that might prevent the Subscription from sending data and keep alive messages, you could increase the RequestedLifetimeCount (and possibly RequestedMaxKeepAliveCount) when creating the Subscription to increase the time it takes before the Subscription is deleted on the Server. The default value for RequestedLifetimeCount is 60, which means that with default RequestedPublishingInterval of 1000 ms, the Subscription will be deleted if there is no communication between the Client and the Server for 60 seconds. If you’re expecting longer connection breaks than that, you should increase the RequestedLifetimeCount. And if you use a shorter RequestedPublishingInterval without changing RequestedLifetimeCount, the Subscription will expire even sooner.

On the other hand, if you’re expecting that your Client might be the side that suddenly stops communicating with the Server, the Server won’t know that it can delete the Subscription and won’t do it until the time determined by RequestedLifetimeCount has expired. Such Subscriptions will continue to consume Server resources until their lifetime expires. If the Server is running on hardware with low computing resources, you must take this into consideration before giving the Subscription arbitrarily long RequestedLifetimeCount.

Hello,

By default the Status of the Server is checked approximately once every second and when a communication fault occurs, the Client will attempt to reconnect to the Server periodically until reconnecting succeeds. After creating a SecureChannel successfully, the Client will attempt to reactivate its previous Session, if it still exists. Otherwise, a new Session will be created and activated. If the Client was able to reactivate its previous Session, it will ask the Server to do a Republish for all Subscriptions. If the Subscriptions no longer exist, the Client will recreate the Subscriptions and their MonitoredItems. Recreating the Subscriptions and MonitoredItems also happens when the Client has to create and activate a new Session.

In short, the Client should be doing everything automatically when reconnecting to a Server after a communication fault.

However, it is important to not call the reconnect method of UaClient instance manually when automatic reconnecting has been enabled, which is the the default for UaClient instances. This could cause the method to be executed in two threads at the same time, which can cause errors as both of the methods would be modifying the same internal parameters of the UaClient instance at the same time. If you would prefer to handle reconnecting manually with a ServerStatusListener for example, you must disable automatic reconnecting by calling the setAutoReconnect(boolean doAutoReconnect) method of the UaClient instance with doAutoReconnect set to false.

Hello,

Your question is quite broad and we can’t provide you with a list of cases that you would need to handle manually. If you have encountered a specific error where you’re unsure whether the Prosys OPC UA SDK for Java is handling it automatically or you need to handle it manually, let us know more about it and we can help.

You would also have to be more specific in your example about Server removing a Subscription. The Client shouldn’t let the Subscription timeout and reconnecting after a CommunicationFault would also recreate the Subscription if needed. If you’re talking about a scenerio where the Server has removed a Subscription for no reason, the Server is not behaving as the OPC UA Specification defines and it is not possible to fix the error automatically. Is this a real scenario that is happening with your Server or a hypothetical one?

Also, it is important to realize that Subscriptions do not guarantee “continuous data read without miss” depending on what you mean with it. Subscriptions are not reading data to begin with but handling DataChangeNotifications sent by the Server. There is sampling involved, which means that there is no guarantee that the Server would report all data changes. That being said, Subscriptions are more efficient than periodic reading so using them is recommended unless you have a specific scenario where they’re unable to sample data changes at sufficient frequency.