ServiceFault is not propagated to client that implemented ServiceFaultListener.

[adrianhoehne]

Hi,
I am confused about a different behavior between 0.6.x and 1.0.

I have a client implementation that registers for ServiceFault events via client::addFaultListener. (The same client also registers for SessionActivities, but ServiceFaults were reported earlier.)

After I unplugged the cable to the server, an event was received with a status of Bad_ServerHalted (I do also handle other...). I used that to recognize that the connection has problems.

In 0.6 it was sent relatively fast. In 1.0 I don't get it at all. Instead, I do get a lot of stack traces with the same status, but the client does not get it, or it happens now after the SessionInactive event.

Is it a default behavior now, or is this a bug?
Did the registration move somewhere else, and the add method is deprecated?

StackTrace of 0.6
`2025-09-29 11:46:12,240 DEBUG [milo-shared-thread-pool-5] (user) OpcUaSubscriptionManager: getTimeoutHint() maxKeepAlive=10000.0 maxPendingPublishes=6 timeoutHint=90000.0
2025-09-29 11:46:12,241 DEBUG [milo-shared-thread-pool-5] (user) OpcUaSubscriptionManager: Sending PublishRequest, requestHandle=163, acknowledgements=[]
2025-09-29 11:46:12,241 DEBUG [milo-shared-thread-pool-5] (user) OpcUaClient: Notifying 2 ServiceFaultListeners
2025-09-29 11:46:12,241 DEBUG [milo-shared-thread-pool-5] (user) UaStackClient: Received ServiceFault request=PublishRequest requestHandle=156, result=StatusCode{name=Bad_ServerHalted, value=0x800E0000, quality=bad}
2025-09-29 11:46:12,242 DEBUG [milo-shared-thread-pool-5] (user) OpcUaSubscriptionManager: Publish service failure (requestHandle=156): StatusCode{name=Bad_ServerHalted, value=0x800E0000, quality=bad}
java.util.concurrent.CompletionException: UaServiceFaultException: status=Bad_ServerHalted, message=The server has stopped and cannot process any requests.
at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:332)
at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:347)
at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:636)
at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
at java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2162)
at org.eclipse.milo.opcua.stack.client.UaStackClient.lambda$deliverResponse$5(UaStackClient.java:337)
at org.eclipse.milo.opcua.stack.core.util.ExecutionQueue$InlineTask.run(ExecutionQueue.java:154)
at org.eclipse.milo.opcua.stack.core.util.ExecutionQueue$Task.run(ExecutionQueue.java:136)
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)
Caused by: org.eclipse.milo.opcua.stack.core.UaServiceFaultException: status=Bad_ServerHalted, description=The server has stopped and cannot process any requests.
... 6 common frames omitted

My logs:
2025-09-29 11:46:12,242 ERROR [milo-shared-thread-pool-2] (user) OpcUaConnector: ServiceFault occured: StatusCode{name=Bad_ServerHalted, value=0x800E0000, quality=bad}
2025-09-29 11:46:12,242 WARN [milo-shared-thread-pool-2] (user) ErrorHandler: 29005 Lost connection to device 'Checkw3 (OPCUA)'`

StackTrace of 1.0
will try to keep it short:

`2025-09-29 11:17:00,807 DEBUG [milo-shared-thread-pool-19] (user) PublishingManager: Sending PublishRequest, requestHandle=13189, acknowledgements=[]
2025-09-29 11:17:00,807 DEBUG [milo-shared-thread-pool-20] (user) PublishingManager: Sending PublishRequest, requestHandle=13191, acknowledgements=[]
2025-09-29 11:17:00,807 DEBUG [milo-shared-thread-pool-22] (user) PublishingManager: Sending PublishRequest, requestHandle=13193, acknowledgements=[]

2025-09-29 11:17:00,807 DEBUG [milo-shared-thread-pool-22] (user) PublishingManager: Publish service failure (requestHandle=13186): StatusCode[name=Bad_ServerHalted, value=0x800E0000, quality=bad]
java.util.concurrent.CompletionException: UaServiceFaultException: status=Bad_ServerHalted, message=The server has stopped and cannot process any requests.
at java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:368)
at java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:377)
at java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1097)
at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
at java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2162)
at org.eclipse.milo.opcua.stack.transport.client.AbstractUascClientTransport.lambda$handleReceiveFailure$6(AbstractUascClientTransport.java:176)
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)
Caused by: org.eclipse.milo.opcua.stack.core.UaServiceFaultException: status=Bad_ServerHalted, description=The server has stopped and cannot process any requests.
at org.eclipse.milo.opcua.stack.transport.client.uasc.UascClientMessageHandler.onSecureMessage(UascClientMessageHandler.java:316)
at org.eclipse.milo.opcua.stack.transport.client.uasc.UascClientMessageHandler.decode(UascClientMessageHandler.java:273)
at io.netty.handler.codec.ByteToMessageCodec$1.decode(ByteToMessageCodec.java:42)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
at io.netty.handler.codec.ByteToMessageCodec.channelRead(ByteToMessageCodec.java:103)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:796)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:732)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:658)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:998)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
... 1 common frames omitted
...
`

That happens a few more times, Then the subscriptions get removed, Then the messages appear again a few times and finally:

`2025-09-29 11:17:02,840 ERROR [milo-netty-event-loop-2] (user) UascClientMessageHandler: [remote=/127.0.0.1:62555] Exception caught: Connection reset
java.net.SocketException: Connection reset
at java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:255)
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:356)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:796)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:732)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:658)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:998)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at java.base/java.lang.Thread.run(Thread.java:840)
2025-09-29 11:17:02,847 DEBUG [milo-netty-event-loop-2] (user) ChannelFsm: channelInactive() local=/127.0.0.1:52157, remote=/127.0.0.1:62555
2025-09-29 11:17:02,849 DEBUG [milo-shared-thread-pool-17] (user) ChannelFsm: S(Connected) x E(ChannelInactive) = S'(ReconnectWait)
2025-09-29 11:17:02,850 DEBUG [milo-shared-thread-pool-17] (user) SessionFsm: ChannelFsm transition from=Connected to=ReconnectWait via=ChannelInactive
2025-09-29 11:17:02,851 DEBUG [milo-shared-thread-pool-21] (user) SessionFsm: S(Active) x E(ConnectionLost) = S'(ReactivatingWait)

2025-09-29 11:17:02,852 ERROR [milo-shared-thread-pool-17] (user) OpcUaConnector: Session Inactive Event: NodeId: NodeId{ns=3, id=1718631869}, Name: UaSession:OpcUaConnector:1759134618127, Timeout:120000.0
2025-09-29 11:17:02,853 WARN [milo-shared-thread-pool-17] (user) ErrorHandler: 29005 Lost connection to device 'Checkw3 (OPCUA)'`

[kevinherron]

After I unplugged the cable to the server, an event was received with a status of Bad_ServerHalted (I do also handle other...). I used that to recognize that the connection has problems.

Differences from 0.6 to 1.0 aside, this never made sense in the first place.

How could a server possibly detect connection loss due to the cable being disconnected and then send something to the client after the fact? This could only be generated by some kind of shutdown event in the server that happens before you pull the cable.

You can use SessionActivityListener::onSessionInactive as an indicator you lost your connection or session. It's also possible to get the ChannelFsm from the underlying OpcTcpClientTransport (OpcUaClient::getTransport) if using opc.tcp, and then add a TransitionListener to it.

--

As to the issue - I think the problem may just be that in 1.0 PublishingManager isn't sending PublishRequests via OpcUaClient::sendRequestAsync and so any ServiceFault that is in response to a PublishRequest isn't getting fired to the listeners. This should be easy to fix. It's probably not what you should be using as any kind of connection indicator though.

[kevinherron]

#1602

[adrianhoehne]

Thank you for reacting so fast.

How could a server possibly detect connection loss due to the cable being disconnected and then send something to the client after the fact? This could only be generated by some kind of shutdown event in the server that happens before you pull the cable.

The client shall detect it, and it worked fine with some subscriptions applied. So, the first subscription that got an error forwarded it, and my client got the ServerFault and reacted to it. The assumption was that if a ServerFault happens to one subscription, it will likely also happen to the others.

The SessionActiveListener::onSessionInactive comes just too late for me but is also already used.

--

As to the issue - I think the problem may just be that in 1.0 PublishingManager isn't sending PublishRequests via OpcUaClient::sendRequestAsync and so any ServiceFault that is in response to a PublishRequest isn't getting fired to the listeners. This should be easy to fix. It's probably not what you should be using as any kind of connection indicator though.

Thanks for that input.

[adrianhoehne]

When is the next release?

[kevinherron]

This week maybe.

[kevinherron]

@adrianhoehne 1.0.6 is released.

[adrianhoehne]

Thank you very much.