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

As my colleague @cmallonee mentioned, for those who need steps to add/modify the websocket max message size for Perspective, you will need to do the following to add the JVM parameter to Ignition:

  1. Open the ignition.conf file that is located in the data folder that’s found in your Ignition installation path
  2. Open the ignition.conf with any text editor
  3. Within the ignition.conf file, scroll down to where it says # Java Additional Parameters; This is the location where JVM parameters are added into Ignition and where we will be adding our web socket max message size parameter
  4. Copy/Paste the following line in the # Java Additional Parameters section of the ignition.conf file:

  1. Replace X in the line with the next sequential parameter number that is seen in the file.
  2. Replace # in the line with the websocket max message size value in KB; The default size is 2048 KB when no value is specified
  3. Save changes to the ignition.conf file; A restart of the Ignition gateway service will be required for the changes to take effect. This can be done by following the instructions that are provided in the following link: Gateway Command-line Utility - gwcmd - Ignition User Manual 8.1 - Ignition Documentation

Here is an example of how the JVM parameter entry would look like :

Doing these steps, the value that was configured will take effect.