AddressSpace.onDataItemsCreated and AddressSpace.onDataItemsDeleted repeatedly firing

I’m currently migrating our 8.1 device implementation to 8.3 and am wondering if anyone else has run into this issue where the onDataItemsCreated/Deleted events seems to constantly be firing. The result is delayed tag reads in the tag browser. I added some logger messages to onDataItemsCreated/Deleted/Modified, and added a tag from our device into the tag browser. The following messages appear.

After about 4 mins, the values begin coming in. Oddly, this seems to affect other tags as well. The random integer and double tag coming from a simulator device go to Uncertain_LastKnownValue and start updating again when the our tags begin updating again. This behaviour doesn’t appear in our 8.1 branch.

We are currently extending the AddressSpaceComposite class for our device implementation and overriding the onDataItems methods.

Hmm, probably something to do with that watchdog timer elapsed warning... I think the subscription/items are being deleted and then created again when that happens.

Set that OpcUaSubscriptionManager logger to TRACE, edit/save the OPC UA connection, then export the logs after a few cycles of this or until your tag manages to stabilize.

edit: org.eclipse.milo.opcua.sdk.client.subscriptions.PublishingManager would be useful too.

server1_Ignition_logs_20250821-1721.idb (320 KB)

Thanks for looking at this Kevin. Let me know if this helps.

Was the PublishingManager logger enabled at the same time as the OpcUaSubscriptionManager logger? There's a long period with no messages from that logger before suddenly everything starts working and then there are also messages from it...

I think the initial PublishRequest is timing out for some reason, and then 3 minutes later once it has timed out and another is sent things start to work...

Does this happen without your module installed? I'm trying to figure out of there's some way for a module to break the publishing mechanism in the server... need to dig more.

Is this something you can reliably reproduce? Does it only happen after a gateway starts up, or can you e.g. disable the OPC UA connection, enable it again, and then observe the same behavior for 3 minutes?

Ok, best guess that shifts the blame away from myself :sweat_smile: is that your module is calling DataItem::setValue with a DataValue that blows up during encoding when the server tries to build a DataChangeNotification and send a PublishResponse.

You aren't ignoring the nullability warnings and trying to stuff a null Variant or StatusCode into DataValue or some kind of illegal value into a Variant by any chance?

Yes.

Don’t believe so. I haven’t tested out any other modules, but I do have a programmable simulator that without the presence of my device’s tags reads immediately. With my tags, it doesn’t read values for the same amount of time as my device’s tags, and then starts reading again after.

Yes I can reproduce. It happens when the server restarts or when I disable/enable the OPC server. I’ll attach another log. I disabled the OPC server at 3:39:28 MDT and re-enable at 3:40:20 MDT.

server1_Ignition_logs_20250821-2148.idb (1.3 MB)

I will admit we do initialize the DataValue with a null value and statuscode Bad_WaitingForInitialValue. I do see in the latest SDK example that I should be using Variant.NULL instead, so I’ll try that. I’m not seeing any compilation errors or warnings, I’m just using the IA Gradle plugin.

Not sure it would be a compiler error, but any IDE should warn you about it: