missing logs

[johannwesely]

In certification process this occured also as an issue:

Diagnostics:

Some Service logs seem to be missing within ‘OpcUa.log’, such as ‘TransferSubscriptions’, ‘SetPublishingMode’, ‘Call’, and “Cancel’. Service calls should be logged if a Bad StatusCode is returned, this is not required for unsupported Services.

Logs for Browse and Write calls exist but contain no StatusCodes.

Suggestion:
Neither Bad Service/OperationResults are logged under [ERROR], only under [DEBUG]. It may be a good idea to add the OPC UA errors also to the list of error reports.

We changed log level to TRACE and there we get SetPublishingMode, Call, Cancel, TransferSubscriptions but no Browse status information. This issue is considered as a warning but they recommendet to fix this.

Greetings Johann

[kevinherron]

It looks like the logger org.eclipse.milo.opcua.sdk.server.OpcUaServer should show all responses on TRACE and exceptional/error responses on DEBUG, which did you have enabled?

[johannwesely]

We enabled TRACE but Browse doesent contain any StatusCode

2025-09-17 13:52:26,391 [DEBUG] 'milo-shared-thread-pool-546' - com.toxware.opcua.server.namespace.DataTypeNamespace: Browsed 10 references for NodeId{ns=5, id=1001}

and when nodeid is unknown the log also i missing.You should add logger to the else cases in ManagedAdressSpace also?

And for the suggestion from allmendiger if it is an error can you mark it as error and not debug?

[johannwesely]

Sorry to bother you but what do you think about my reply last week ?

[kevinherron]

I'll take a closer look when I'm back home on Sunday or Monday.

There might be some room to improve logging for the services in general, either in Default*ServiceSet for each service group, or in OpcUaServer.ServerApplicationContextImpl.

I'm not interested in changing bad service results to ERROR or WARN level as they suggest. In my view these are "expected" and should not be visible or fill a log file up by default when repeated. There are diagnostic counters that can indicate a problem that warrants further investigation and log level changes.

[kevinherron]

Another idea might be to make it possible for a user to somehow listen for service results, kind of like on the client side where there is a ServiceFaultListener that can be added via OpcUaClient::addFaultListener.

This way the application can decide how to log.

Generally, I think that since Milo is a library it should minimize the amount of logging it does on INFO/WARN/ERROR.

[kevinherron]

Ok I'm still not sure what to do here.

Service-level errors are already logged on DEBUG via org.eclipse.milo.opcua.sdk.server.OpcUaServer, e.g.

[milo-shared-thread-pool-0] DEBUG org.eclipse.milo.opcua.sdk.server.OpcUaServer - Service request completed exceptionally: path=/milo handle=3 service=VIEW_BROWSE remote=/10.10.70.96:51734
UaException: status=Bad_NothingToDo, message=No processing could be done because there was nothing to do.
	at org.eclipse.milo.opcua.stack.core.util.FutureUtils.failedUaFuture(FutureUtils.java:111)
	at org.eclipse.milo.opcua.stack.core.util.FutureUtils.failedUaFuture(FutureUtils.java:99)
	at org.eclipse.milo.opcua.sdk.server.servicesets.impl.DefaultViewServiceSet.browse(DefaultViewServiceSet.java:160)
	at org.eclipse.milo.opcua.sdk.server.servicesets.impl.DefaultViewServiceSet.onBrowse(DefaultViewServiceSet.java:65)
	at org.eclipse.milo.opcua.sdk.server.AbstractServiceHandler.lambda$addServiceSet$30(AbstractServiceHandler.java:239)
	at org.eclipse.milo.opcua.sdk.server.OpcUaServer$ServerApplicationContextImpl.handleServiceRequest(OpcUaServer.java:638)
	at org.eclipse.milo.opcua.sdk.server.OpcUaServer$ServerApplicationContextImpl.lambda$handleServiceRequest$0(OpcUaServer.java:557)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:840)

Operation-level logging can be better and needs to be considered per service implementation.