Hi all,
I have a query returning 3000 plus rows and have the return format set to JSON, so I can use one embedded view (for styling purposes), displayed with the rest of the data.
I keep getting a Message too big message, and the Designer loses connection with the GW.
In another project, I have the exact same setup but it does not lose connection. If you ask why the same setup, I am rebuilding this project into the new one.
This is the message from the GW Log:
Websocket connection closed unexpectedly. code=1009, reason=Text message too large: (actual) 2,103,240 > (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.
I have seen Phil mention chunking datasets here and there, but not sure how to do that.
I could limit the query in SQL Server, then send a new query request based on user input.
Or, I could change the max message size, but I did not see anything relating to this in the conf file.
Advice is appreciated.
EDIT: I just realized that by limiting the size from the DB would also affect using the table filter. So, if there is a way to chunk the data maybe as it loads into the View or Table?
Is this in a binding that you are returning this?
I'm pretty sure theres a bunch of threads where massive datasets were sent from the gateway using message handlers and sidestep this completely.
I’m going to assume a few things based on your message. Assume you have a binding on your view called view.custom.data that is holding your large dataset. You then have an embedded view that you are passing the data into, and within that embedded view, you assumably have a table.
If the table is not virtualized, you are sending 3 copies of that data to the browser DOM.
view.custom.data- Embedded view prop
- Table.props.data
You could set view.custom.data to Access: Private, which would stop it from propagating to the DOM. You now have 2 copies of the data being sent.
You could virtualize the table and add pagination, which only sends the visible rows to the DOM. You now have 1.01 copies sent to the DOM (25 out of 3,000 rows)
Unfortunately, the only way to remove the last fully copy is to not send the data to an embedded view. You can add the table to your view, and then use the Advanced Stylesheet to build a style class to apply to your table for consistency.
1 Like
Yes, this is a named query binding to a custom property.
The table itself is not embedded, but has a couple of cells with embedded views.
This problem was occurring in the Designer, and according to the Docs the private property is used by the browser DOM. So why would this change anything in the Designer?
I always leave the table.props.pager enabled, unless it's a very small dataset.
The Designer's allocated memory is 6144 MB.
@David_Stone
How different is that from using a binding? I assume that the binding would be loading earlier, probably while the view's components load, whereas using a message handler might delay the dataset load a second or two?
Curiously enough, I've been working with this for the last hour, pretty sure everything is the same as it was when I had the errors, but now things are going smoothly.
And it's been another hour or so, still going well. This issue seems to have resolved itself somehow, for now anyway! 
Thank you for taking the time to reply!
You should definitely ensure you have the access set to private on custom properties that don’t need to make their way to the client
Unfortunately, pagination on the table component does not limit the data being sent to the client.
The table component filters in the client and therefore, regardless of the pagination setting, the entire dataset is sent to the dom. Initially the data is sent in the http response not through the websocket so it will load up fine to start.
Normally this is only an issue for the websocket if the filter results option is enabled and the user enters some filter text. At that point the table component populates the filter result data property and sends the result data set back to the gateway through the websocket, uncompressed, not chunked, which breaks the websocket and nerfs the session.
@mdermaris you can increase the size of the websocket in the gateway config Gateway configuration reference
I would suggest you do your own pagination and filtering on the binding rather than using the built in features of the table component, to limit the number of records being bound to the table.props.data. It is the safest way until this component gets some love IMO.
1 Like