I should also add, that the PublishInterval, MaxKeepAlive and LifetimeCount of a Subscription + the SamplingInterval of MonitoredItems are requests to the server, it is allowed to revise them to other values: https://reference.opcfoundation.org/Core/docs/Part4/5.12.2/ https://reference.opcfoundation.org/Core/docs/Part4/5.13.2/. While most likely most servers should accept e.g. 1000 and 250, some might not, if they would have e.g. fixed publishinterval + samplinginterval “loops of fixed time” (like e.g. a µController interupts with timers etc.).

1. Ok, I guess then I need to know if the server is made with our (java) SDK or is it something else (per your 3. answer I think it is not). Anyway, the way our server side handles things might differ a bit what might be generally done, but we pretty much emulate what should happen (i.e. we do not exactly “really sample” there, since the data is typically in the UaNode objects, so we instead calculate to which sampling interval a value change should be).

Thus then we would need to know how often the data really changes in the server and can it change to the same value (e.g. let’s say the data would be a temperature sensor, it could be constant for long times). For the default/null only-status-and-value-changed trigger, you would only get a single notification of that (the initial value). If you want the notifications also from status-value-and-timestamp changes, use code explained in https://forum.prosysopc.com/forum/opc-ua-java-sdk/datachange-notification-when-value-doesnt-change/#p4265 and put that to the item (preferably before adding it to the subscription).

2. Hmm.. maybe here it wont matter, but in general the MaxKeepAliveCount and LifetimeCounts typically should change if the PublishInterval is changed. Or like, it depends, in this case with 250 it might not matter. The periods for keepalive sending and lifetimecount (after which the server deletes the subscription if no PublishRequest has arrived which could be used to send a keepalive if no data has changed) are multiples of the publishinterval. So e.g. if the PublishInterval was set to 100 while keeping our default 20 for the maxkeepalive it would be only 2 seconds before a keepalive would be sent. And with 60 then the lifetime would be 6s. If connection is stable etc. no problem, but if there is a connection break then basically if it would be larger than ~6 seconds the subscription would have been deleted on the server.

3. Ok, then there shouldn’t be anything affecting this directly in the newer versions: https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html, but in general we do of course recommend updating to the latest version.

4. Then I think you can ignore that error code. It might be a race condition, but basically that is what server would most likely send back for the remaining PublishRequest we have queue’d there. It is possible that it returned them faster than we could locally handle the remove operation. Technically we do call the DeleteSubscriptions service call before we remove the Subscription from local list and the responses are handled in a separate thread, thus most likely the response arrived before we did the remove. Should most likely be done better, but shouldn’t impact anything (other than the log).