Error when trying to read custom device tags

Hello, I’m currently doing some stress testing of an OPC device module in 8.3 and I’ve run into the following error when I try to read my tags in the 8.3 designer:

16:05:32.360 [WebSocket@857682732-49] ERROR com.inductiveautomation.ignition.client.gateway_interface.GatewayConnectionManager -- WebSocket error
org.eclipse.jetty.websocket.api.exceptions.MessageTooLargeException: Binary message too large: 2,097,750 > 2,097,152
at org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler.convertCause(JettyWebSocketFrameHandler.java:424)
at org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler.onError(JettyWebSocketFrameHandler.java:240)
at org.eclipse.jetty.websocket.core.WebSocketCoreSession.lambda$closeConnection$2(WebSocketCoreSession.java:260)
at org.eclipse.jetty.websocket.core.WebSocketCoreSession.handle(WebSocketCoreSession.java:106)
at org.eclipse.jetty.websocket.core.WebSocketCoreSession.closeConnection(WebSocketCoreSession.java:260)
at org.eclipse.jetty.websocket.core.WebSocketCoreSession.lambda$sendFrame$7(WebSocketCoreSession.java:501)
at org.eclipse.jetty.util.Callback$3.succeeded(Callback.java:170)
at org.eclipse.jetty.websocket.core.util.TransformingFlusher.notifyCallbackSuccess(TransformingFlusher.java:195)
at org.eclipse.jetty.websocket.core.util.TransformingFlusher$Flusher.process(TransformingFlusher.java:152)
at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:262)
at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:243)
at org.eclipse.jetty.websocket.core.util.TransformingFlusher.sendFrame(TransformingFlusher.java:78)
at org.eclipse.jetty.websocket.core.WebSocketCoreSession.sendFrame(WebSocketCoreSession.java:504)
at org.eclipse.jetty.websocket.core.WebSocketCoreSession.close(WebSocketCoreSession.java:212)
at org.eclipse.jetty.websocket.core.WebSocketCoreSession.processHandlerError(WebSocketCoreSession.java:354)
at org.eclipse.jetty.websocket.core.WebSocketConnection$1.failed(WebSocketConnection.java:278)
at org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler.lambda$onFrame$2(JettyWebSocketFrameHandler.java:231)
at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture.uniWhenCompleteStage(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture.whenComplete(Unknown Source)
at org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler.onFrame(JettyWebSocketFrameHandler.java:226)
at org.eclipse.jetty.websocket.core.WebSocketCoreSession$IncomingAdaptor.lambda$onFrame$0(WebSocketCoreSession.java:647)
at org.eclipse.jetty.websocket.core.WebSocketCoreSession.handle(WebSocketCoreSession.java:106)
at org.eclipse.jetty.websocket.core.WebSocketCoreSession$IncomingAdaptor.onFrame(WebSocketCoreSession.java:647)
at org.eclipse.jetty.websocket.core.ExtensionStack.onFrame(ExtensionStack.java:113)
at org.eclipse.jetty.websocket.core.WebSocketCoreSession.onFrame(WebSocketCoreSession.java:463)
at org.eclipse.jetty.websocket.core.WebSocketConnection.onFrame(WebSocketConnection.java:254)
at org.eclipse.jetty.websocket.core.WebSocketConnection.fillAndParse(WebSocketConnection.java:447)
at org.eclipse.jetty.websocket.core.WebSocketConnection.onFillable(WebSocketConnection.java:332)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99)
at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:478)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:441)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.eclipse.jetty.websocket.core.exception.MessageTooLargeException: Binary message too large: 2,097,750 > 2,097,152
at org.eclipse.jetty.websocket.core.messages.ByteBufferMessageSink.accept(ByteBufferMessageSink.java:71)
at org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler.acceptFrame(JettyWebSocketFrameHandler.java:397)
at org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler.onContinuationFrame(JettyWebSocketFrameHandler.java:380)
at org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler.onFrame(JettyWebSocketFrameHandler.java:218)
... 20 common frames omitted

For background, I had an 8.1 testing environment where I had 1300 devices reading 9100 tags. When examining those tags in the 8.1 designer, it took a bit of time but the values would eventually load and be visible. I migrated the environment to 8.3 along with the module and this is what I’m seeing now. Many of my values are coming through and some are not, but eventually the designer disconnects from the gateway with the above stack trace. I’m also noticing some warnings in the gateway like this from org.eclipse.milo.opcua.stack.transport.client.tcp.OpcTcpClientTransport:

Received response for unknown request, requestId=1728

There’s no stack trace, so there’s no other messages. Is this something I can fix by adding a line in the gateway.xml file or ignition.conf file? Or is it something else?

You can set -Dignition.designer.websocketMaxBinaryMessageSize=4096 (default value is 2048) in your designer launcher configuration:

This raises the maximum message size the designer will accept, which should allow you to get past this issue for testing.

In some near future release (possibly as early as 8.3.1, potentially later) we're going to change the way large notification messages are delivered to the client/designer to help work around this issue as a stopgap.
In some farther future release, we're going to change the way tag values are delivered to the client/designer completely to take better advantage of the new persistent websocket that's available as of 8.3.

I think that resolved it. Thanks Paul.

Eden, please see Wiki - how to post code on this forum. (You've posted your error log as a quotation instead of preformatted text. The preformatted text option limits the length of your post by adding a scroll bar to the text block and keeps the forum tidy.)

I'm getting this in 8.3.7 trying to simply open tag browser.

We already had the setting set to 4MB, but we're getting the limit reached again:

WebSocket closed with statusCode='1009', reason='Binary message too large: 4,197,538 > 4,194,304'

I tried updating to double it again, but that doesn't seem to have had any effect...

wrapper.java.additional.9=-Dignition.designer.websocketMaxBinaryMessageSize=8192

Is there a limit to this @paul-griffith ?

And are there any other websocket size related arguments NOT specific to the Designer? I feel like we're getting issues all over the place with gateway/client comms after updating to 8.3

Managed to sort our issues increasing to 16MB (16384).

The designer arg applies to both the Vision client and the designer, and can be changed independently on the 'client' side or the 'server' side (the gateway), which will depend on where the source of the actual large message is.

The work missed 8.3.8, but I'm actively working on the aforementioned improvements to sync. If all goes well, that should make it into 8.3.9.