Syncronize ServerTimestamp

[johannwesely]

Hello,
is there a possibilty to syncronize the servertimestamp ? I have the following Problem i write a linkedlist of Values directly to server within a loop

for (Map.Entry<NodeId, List<Object>> entry : valuesToWrite.entrySet()) {			
			if (serverNode.isPresent() && serverNode.get() instanceof UaVariableNode variableNode) {
				//check if identifiers match serverNode <---> xmlNodetoValueMap
				Variant v = OpcUaDataVerification.getVariant(entry.getValue(), variableNode, server.getServer().getEncodingContext());
				variableNode.setValue(new DataValue(v));
				}
			}

and the sourceTimestamps are in syncronous Order(values with sorted sourceTimestamp):

now the server Timestamp comes in an different Order(values sorted by serverTimestamp):

So the DatapublishTrigger Value which i want to be set as the last value comes somwhere inbetween. Is there a config or suggestion to archive the same order of server Timestamps like the sourceTimestamps ?

[johannwesely]

Sorry i just realized the pictures where cut off

[kevinherron]

Are you using org.eclipse.milo.opcua.sdk.server.util.SubscriptionModel in your address space that these Nodes belong to?

I can't see why the server timestamps would get replaced or be out of order except if they are later modified outside your loop, which happens here if you use SubscriptionModel:

milo/opc-ua-sdk/sdk-server/src/main/java/org/eclipse/milo/opcua/sdk/server/util/SubscriptionModel.java

Lines 190 to 193 in 128cd77

	value =
	(AttributeId.Value.isEqual(attributeId))
	? DataValue.derivedValue(value, timestamps)
	: DataValue.derivedNonValue(value, timestamps);

in

milo/opc-ua-stack/stack-core/src/main/java/org/eclipse/milo/opcua/stack/core/types/builtin/DataValue.java

Lines 183 to 194 in 128cd77

	public static DataValue derivedValue(DataValue from, TimestampsToReturn timestamps) {
	boolean includeSource =
	timestamps == TimestampsToReturn.Source || timestamps == TimestampsToReturn.Both;
	boolean includeServer =
	timestamps == TimestampsToReturn.Server || timestamps == TimestampsToReturn.Both;
	return new DataValue(
	from.value,
	from.status,
	includeSource ? from.sourceTime : null,
	includeServer ? DateTime.now() : null);
	}

[kevinherron]

ServerTimestamp is always supposed to be "fresh" - at the time a value is read or polled, so it's not expected that you would be updating yourself underneath this naive subscription mechanism.

[johannwesely]

Hi we are using SubscriptionModel, so can you explain to me the meaning of servertimestamp because my understandig was i write a value and ServerTiemstamp shows that the value is accurate. So what we we want is to set the DataPublishTrigger Value when all the other Data is accurate. We have investigated this case further and we think we have the following Problem:

• Value is set
• Value ends up asynchronously in the queue of the monitored-item node.
• PublishTrigger is set and is faster in the queue
• Data is sent after x-millisecond publish interval.
• Data loss occurs when Publish Interval strikes after trigger is in queue, but ToolId is not, for example, yet.
  Is there soemthing like ready-to-publish or item-is-in-queue where we can check/control the queue? Greetings Johann

[kevinherron]

SourceTimestamp vs ServerTimestamp are explained here:
https://reference.opcfoundation.org/Core/Part4/v105/docs/7.11.3
https://reference.opcfoundation.org/Core/Part4/v105/docs/7.11.4

The key thing to take away is that the ServerTimestamp is expected to continually change; you set the value and it locks in the SourceTimestamp, and then even if the value does not further change, and a Client subsequently reads that value every second, the ServerTimestamp will update each time a value is returned in response, because the server "knew it to be accurate" at that point still. The SourceTimestamp would remain the same.

You have no control over how/when queued data change notifications are sent to the client. If you need to ensure multiple datapoints are published atomically then consider packing them into a structure.

It might also be possible to get the behavior you seek if you control the Client, by using the SetTriggering service, along with ensuring on the Server side you update the other items before the trigger item.

[johannwesely]

Hi Kevin,
The Client already uses the setTriggering Service and the Items are allready linked. The Value of the DatapublishTrigger is beeing changed at last. How can we make shure that it lands in the queue as last?
Sampling Interval is 100ms
Monitoring Mode Items to Report is Sampling.
MonitoringMode for Triggering Item is Reporting.

Greetings Johann

[kevinherron]

One thing that might help is to introduce a lock to prevent sampling from occurring at the same time as you're updating Nodes.

Something like:

  private final ReadWriteLock readWriteLock = new ReentrantReadWriteLock(true);

  @Override
  public List<DataValue> read(
      ReadContext context,
      Double maxAge,
      TimestampsToReturn timestamps,
      List<ReadValueId> readValueIds) {

    try {
      readWriteLock.readLock().lock();
      return super.read(context, maxAge, timestamps, readValueIds);
    } finally {
      readWriteLock.readLock().unlock();
    }
  }

and then in your code that updates the Nodes you would acquire readWriteLock.writeLock() first.

This only solves one race, though. The Subscription will still be evaluating at its publishing interval independently from the sampling, and I think there's still some small chance a Subscription runs through its items to determine if they have anything queued or have been triggered at the same time that the sampling logic is looping through and setting values.

That publishing and sampling are decoupled is by design in OPC UA.

None of this would resolve your ServerTimestamp problem, either. You could force your way around that by doing sampling yourself instead of using the SubscriptionModel class.

And again, if you have multiple data points that should update and be delivered atomically, then put them into a structure and publish the structure value. This is the only way to guarantee that a client receives them atomically.