### Description
By using the WebSocket module we noticed that the memory on the server keeps increasing daily even if the number of registered devices is decreasing
### Troubleshooting
#### Reproduction
Connect to the server through the wss and then disable the network adapter.
#### Debugging Data
If the TCP connection is closed forcefully (tested by disabling network adapter) then the number of current wss connections is not decreasing:
``` kamcmd stats.get_statistics all | grep "ws_current_connections" ``` The same happens with the allocated shared memory: ``` kamcmd mod.stats all shm | grep 'wsconn_' ``` wsconn_add(198) - this value is not decreasing. Everything is working properly if the TCP connection is properly closed.
* **Operating System**:
``` CentOS 7 X64 3.10.0-1160.76.1.el7.x86_64 version: kamailio 5.6.1 (x86_64/linux) d8f98b ``` XHTTP Request Route:
``` event_route[xhttp:request] { set_reply_close(); set_reply_no_connect();
if (ws_handle_handshake()) { xlog("L_INFO", "[$cfg(route)] websocket|log|handled HTTP request $rm from $si:$sp\n"); exit; } } ```
TCP Settings: ``` tcp_connection_lifetime=3605 tcp_accept_no_cl=yes tcp_rd_buf_size=16384 tcp_connect_timeout=10 tcp_crlf_ping=yes tcp_delayed_ack = yes tcp_fd_cache = yes tcp_keepalive = yes tcp_keepcnt = 3 tcp_keepidle = 30 tcp_keepintvl = 10 tcp_accept_aliases=no tcp_async=yes tcp_linger2=30 tcp_max_connections=4096 tcp_send_timeout = 10 ```
You should check if the connections are still open at the OS level (e.g., using netstat).
Also, there is a rpc command to list the websocket connections, use it to see what gives back.
Yes, sorry forgot to mention that the TCP connection at the OS level is closed. Also, command: ``` kamcmd ws.dump ``` showing an empty output.
Can you try with git master branch or using the patch from the commit referenced above?
@miconda - works like a charm now. Thank's a lot! I will keep testing it for a couple of days and will let you know of any issues.
Closed #3236 as completed.
No issues so far, everything works as expected. Thanks, Daniel for looking into that.