At FBW, we are using JS Websockets to enable a remote MCDU functionality. To
connect with the server, we’re attempting to connect to a local Websocket
server in regular intervals (currently every 5 seconds). If that fails, it
seems like the Websocket object is not closed properly but can also not be
reused for a further connection. The “onerror” and “onclosed” handlers are not
called as well. Subsequent reconnect attempts will create a new object with
the same behaviour. This might lead to performance and memory issues some
users experience, especially after long flights. The open sockets can also be
seen in the Coherent Debugger (see screenshot, [Full res](https://user-
images.githubusercontent.com/19493808/159038154-3dc5fcd0-00bc-4c48-acd7-bfebaefdf904.png)
).
by closing the object explicitly, which properly releases the object (i.e. not
visible in the debugger anymore). But that was causing additional overhead,
where a close operation would take up to 2.5s according to the debugger,
leading to a stutters and freezes. Next attempt was to use the fetch API for
checking whether the Server is alive prior to establishing the Websocket
connection. However this also had a significant impact on performance, mainly
noticeable in the CoherentGTUI thread, when a request fails. To my knowledge
the sockets should be automatically closed and disposed upon a failed
connection attempt. If needed, the affected code can be found
[here](https://github.com/Saschl/a32nx/blob/d45c41116d18688eab28a227800698dcbfe45719/flybywire-
aircraft-a320-neo/html_ui/Pages/VCockpit/Instruments/Airliners/FlyByWire_A320_Neo/CDU/A320_Neo_CDU_MainDisplay.js#L296-L300)
and
[here](https://github.com/Saschl/a32nx/blob/d45c41116d18688eab28a227800698dcbfe45719/flybywire-
aircraft-a320-neo/html_ui/Pages/VCockpit/Instruments/Airliners/FlyByWire_A320_Neo/CDU/A320_Neo_CDU_MainDisplay.js#L1429-L1464)
Regards,
)