Websocket Disconnected Because DataFrame/Message Too Large with Perspective

Hello,

I am receiving this error in the logs -

Websocket connection closed unexpectedly. 
code=1009, 
reason=Resulting message size [2102265] is too large for configured max of [2097152], codeMeaning=Message Too Big, 
codeDescription=The endpoint is terminating the connection because a data frame was received that is too large.

I am working with some large dictionary structures, and passing them as parameters across different embedded views. I'm optimizing my strcuts to decrease the size of data. I have a couple of questions.

Would I be better to use a dataset or a JSON encoded dictionary to pass parameters instead of a Perspective Object? Maybe the best question here is what is the most data-friendly structure to use (lists vs datasets vs objects vs JSON-encoded objects/lists)

Lastly, where can I increase the max message size, and is this a bad idea to do so?

Thanks!!

Trent

Datasets are better, generally, because they have an optimization throughout of not needing to render (and listen for changes on) all inner members.

Making properties private also helps a lot, though I don't know if you can do that for view parameters. I would consider different approaches; can you 'batch process' this data entirely on the gateway so you don't have to send so much between views at all?

1 Like

I've been getting this issue whenever a filter is applied to an alarm journal, unless the date range being viewed is small (a few weeks). I'm afraid to allow the toolbar to be visible in case someone applies an Active filter to what would be a beginning of time view of all historical alarms. I've tried changing the max data frame size, but then it always tries to send something just slightly bigger than the new maximum and disconnects the clients.

I ended up having to go pretty big on that max message size for some of the larger datasets that have tens of thousands or hundreds of thousands of rows for Perspective

I forgot to follow up on the issue here. The solution to my particular problem was to not use the native filter, but to instead filter using the filterAlarm extended function, which is a lot faster:

return "Active" == str(alarmEvent.get('EventState'))
1 Like

I noticed that this also happens when:

  1. I drag a perspective table column into another position, with about 3500 rows. Yet does not happen in other tables.
  2. It also happened in the designer, when I copied the table.props.columns into Notepad ++ to reorder the columns and pasted the JSON back into the table props. I had a large message on the view that said lost connection to gateway.

The error message is similar to others mentioned on this topic, where the dataframe was too large:

Websocket connection closed unexpectedly. code=1009, reason=Text message too large: (actual) 2,101,363 > (configured max text message size) 2,097,152, codeMeaning=Message Too Big, codeDescription=The endpoint is terminating the connection because a data frame was received that is too large.

Not sure what I did, but now this is happening non-stop:
image

From the designer, same view I was working with earlier when I copy/pasted the table column JSON.

Console says:

18:05:44.230 [Browser Thread: 623bfa41-e904-46b9-9591-9ae35c26491f] INFO Perspective.Designer.Workspace -- store.Channel: Websocket connection closed. code=1006, wasClean=false, reason=No reason given, codeMeaning=Normal Closure, codeDescription=Reserved. Indicates that a connection was closed abnormally (that is, with no close frame being sent) when a status code is expected.

Edit:
Just noticed that the memory seems kinda high:


I have the one view open, and am the only user with an open designer.

Edit 2:
Just realized that one of the table's columns uses an embedded view, and I added the key and value parameters... The key contained the whole collection of data :man_facepalming: I think this might could cause an issue...