Gateway Crashing when passing view parameter

The websocket message contains all of the literal bits required to tell the browser how to render the page, so everything from the HTML which constructs the components, to the JavaScript which defines how those components change on update, to any and all properties for each component/view. So if the problem occurs when you first open the page, it’s likely the View is “too large” or complex for the websocket to send the definition of the View in use. If you encounter this after the page loads, then it’s likely the page is not the problem, but rather data being sent to the page a s the result of an updated binding or property write. Occurrences on initial load could also be a data/binding problem as the data stored in the view could result in the definition becoming too large.

1 Like

These two views don’t have any bindings that would contain large amounts of data. They are not “larger” or more complex than other views in the project. They may even be a bit less complicated/smaller that some others.
I would think that if were a view specific issue, the two views would also be crashing the WebSocket on our QA and Val servers, since the views/projects are the same across all servers.

Sorry, but without really in-depth access I’ve reached the extent to which I can help diagnose the problem. You could contact support to help examine the environments in question and locate the difference, but I’m not in a position to make guesses or troubleshoot your deployments. My help here on the forums boils down to things I know or can research.

You were right! There was some old content that had been disabled (display set to false), but there was a query binding that was still active. Since the three servers have separate DBs, the other two were not accumulating as much data as the production server, since they are only used for testing, not nearly as much data has built up in their DBs. The biding on the production server created a dataset with 58K+ rows of data.

The reason for the disabling and not summarily deleting the content was due to the nature of the facility shifting back and forth on what they may or may not want over a period of time. So in the future, if we are directed to disable content, we need to be aware of any binding and such that could be problematic.

We did have Tech Support remote in to look (before we found the above content) and they increased the socket max value. That got us up and running. I’ll be working on a bug fix branch to remedy this and look through the other content to make sure there isn’t other monsters hiding, and waiting to attack!

Thanks for your help!

1 Like