# Websocket connection closed unexpectedly **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [June 17, 2024, 12:43pm UTC](https://forum.inductiveautomation.com/t/websocket-connection-closed-unexpectedly/91944 "2024-06-17T12:43:36Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![edward.fowler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/edward.fowler/32/24179_2.png) [@edward.fowler](https://forum.inductiveautomation.com/u/edward.fowler)\ **Post date:** [June 17, 2024, 12:43pm UTC](https://forum.inductiveautomation.com/t/websocket-connection-closed-unexpectedly/91944/1 "2024-06-17T12:43:36Z")
> Websocket connection closed unexpectedly. code=1009, reason=Text message too large: (actual) 2,098,113 \> (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. There are a few forum topics about this. Our Perspective pages and views haven't changed in about a year and a half and in that time we've seen perhaps two lost connection banners. Now, it's happening several times a day. What could be causing this when nothing has been changed in Designer? Unlike the related topics below, our pages/view are relatively simple, no images, no tables, just tag values, gauges, and power charts. Related topics: [https://forum.inductiveautomation.com/t/text-message-size-exceeds-maximum-size-message-too-big/80207/2](https://forum.inductiveautomation.com/t/text-message-size-exceeds-maximum-size-message-too-big/80207/2) [https://forum.inductiveautomation.com/t/websocket-disconnected-because-dataframe-message-too-large-with-perspective/67391/5](https://forum.inductiveautomation.com/t/websocket-disconnected-because-dataframe-message-too-large-with-perspective/67391/5) x ---
**Author:** ![bschroeder](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bschroeder/32/13260_2.png) [@bschroeder](https://forum.inductiveautomation.com/u/bschroeder)\ **Post date:** [June 17, 2024, 1:00pm UTC](https://forum.inductiveautomation.com/t/websocket-connection-closed-unexpectedly/91944/2 "2024-06-17T13:00:38Z")
Any firewall changes? OS updates? Are you running in Workstation or in the browser? ---
**Author:** ![edward.fowler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/edward.fowler/32/24179_2.png) [@edward.fowler](https://forum.inductiveautomation.com/u/edward.fowler)\ **Post date:** [June 17, 2024, 1:11pm UTC](https://forum.inductiveautomation.com/t/websocket-connection-closed-unexpectedly/91944/3 "2024-06-17T13:11:57Z")
Should have mentioned v8.1.31 No OS updates in a year. No firewall changes (directly connected on the LAN, not going through the firewall). Chrome. Web inspector console indicates more. > store.Channel: Websocket connection closed. code=1009, wasClean=false, reason=Text message too large: (actual) 2,104,643 \> (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. > PerspectiveClient.18a5e9a5f5264ddeb349.js:2 > > store.Channel: Websocket connection closed. code=1009, wasClean=false, reason=Text message too large: (actual) 2,101,610 \> (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. > PerspectiveClient.18a5e9a5f5264ddeb349.js:2 > > 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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [June 17, 2024, 1:22pm UTC](https://forum.inductiveautomation.com/t/websocket-connection-closed-unexpectedly/91944/4 "2024-06-17T13:22:12Z")
I would suspect a higher data demand on a user-configurable component, like chart pens or a chart's time span. ---
**Author:** ![edward.fowler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/edward.fowler/32/24179_2.png) [@edward.fowler](https://forum.inductiveautomation.com/u/edward.fowler)\ **Post date:** [June 17, 2024, 1:32pm UTC](https://forum.inductiveautomation.com/t/websocket-connection-closed-unexpectedly/91944/5 "2024-06-17T13:32:15Z")
Thanks @pturmel , thought about that, but the users aren't changing anything in the chart configuration. ---
**Author:** ![edward.fowler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/edward.fowler/32/24179_2.png) [@edward.fowler](https://forum.inductiveautomation.com/u/edward.fowler)\ **Post date:** [June 19, 2024, 1:57pm UTC](https://forum.inductiveautomation.com/t/websocket-connection-closed-unexpectedly/91944/6 "2024-06-19T13:57:33Z")
This topic is similar to > [@Websocket max message size exceeded in Perspective when lots of alarms in Alarm Status Table](https://forum.inductiveautomation.com/t/websocket-max-message-size-exceeded-in-perspective-when-lots-of-alarms-in-alarm-status-table/78095): > > I'm building a Perspective screen with an alarm status table for a large system with lots of alarms. I am simulating the devices for now using the built-in device simulator in Ignition so a lot of alarms are triggered at the same time. When the alarms come in, I get a "Lost Connection to gateway" message in the designer and in the perspective client. The error message is below: I found a post for a similar issue, but am wondering if there is some way to optimize the alarm status tabl… The alarm status table had about 1000 unacknowledged alarms. The issue cleared up after acknowledging them. It took some time as I kept losing the connection, but it improved as more and more alarms were acknowledged. Another note on this, it also happened on views that didn't include the alarm status table, just some alarm counts in a view header (query driven). ---
**Author:** ![tyler.bennett](https://avatars.discourse-cdn.com/v4/letter/t/f04885/32.png) [@tyler.bennett](https://forum.inductiveautomation.com/u/tyler.bennett)\ **Post date:** [December 18, 2024, 1:50am UTC](https://forum.inductiveautomation.com/t/websocket-connection-closed-unexpectedly/91944/7 "2024-12-18T01:50:24Z")
Here is a script that can be used to acknowledge all alarms from the script console. ```python alarms = system.alarm.queryStatus(state = [0, 2]) # 0 is Clear Unacked, 2 is Active Unacked print "Unacked alarms before:", len(alarms) notes = None alarmIds = [str(alarm.eventid) for alarm in alarms] system.alarm.acknowledge(alarmIds, notes) alarms = system.alarm.queryStatus(state = [0, 2]) print "Unacked alarms after:", len(alarms) ``` Encountered this issue again. We use a lot of embedded views for display and each one queries the alarm status to find out if its tag is in alarm and if so display an alarm indication. May need to revisit and optimize that implementation, 740 unacked alarms shouldn't take down the UI. ---
**Author:** ![Simen](https://avatars.discourse-cdn.com/v4/letter/s/7cd45c/32.png) [@Simen](https://forum.inductiveautomation.com/u/Simen)\ **Post date:** [December 18, 2024, 12:00pm UTC](https://forum.inductiveautomation.com/t/websocket-connection-closed-unexpectedly/91944/8 "2024-12-18T12:00:33Z")
You will likely encounter this issue if you remove all filters on the alarm status object, maybe you have to search, cant really remember, but i found a consistent way to break it by interacting with the alarm object. Im also pretty sure this was the fix: In igntion.config, exchange the number 8 for a unused number. `wrapper.java.additional.8=-Dperspective.websocket.max-message-size=4096` Gateway has to be restarted for the change to take effect. Not really sure how many alarms this is good for, but its enough for me..