Hey all!
I’ve got a phoenix server running 4 endpoints using main_proxy to route to them. Running OTP 26.0.2, Elixir 1.15.2, Phoenix 1.7.6 & LiveView 0.18.18. The server itself is behind nginx. It’s running in a docker container via dokku, and deployed via mix not a release.
Websocket connections are accepted for LiveView on 3 of the endpoints. The remaining endpoint accepts websocket connections for iOS clients.
I’ve been having issues recently where I’m told that sometimes the iOS clients aren’t syncing data (which is what they do when they connect to a socket, then to the sync channel).
Having a look at phoenix_live_dashboard over time, it seems that the number of sockets keeps increasing.
After boot the server has about 330 sockets. Fast forward 2 days and there’s over 2000. It’s expected that more sockets will be used up as more clients connect. But they should also disappear eventually.
Having a look at each of these sockets I have quite a number of them that look like they’re orphans — but I’m not sure if this is normal 
. This is what I mean:
There are currently a number of connections with 3.1kb sent and between 4kb and 13kb received. This doesn’t increase:
Here’s the detail:
Clicking into the owner PID shows no monitors and nothing monitored by:
My question is — is this normal to have these? If not, has anyone got any ideas on how I can go about figuring out what’s causing them and ultimately how to ensure they don’t occur?
Thanks!
1 Like
After downgrading back to OTP 25 (25.3.2.4) this problem went away. 
1 Like
I spoke too soon in my earlier post. This was still an issue — even after downgrading to OTP 25. It has since been resolved, so I can answer my previous questions (in case this helps anywho who follows).
There are currently a number of connections with 3.1kb sent and between 4kb and 13kb received. This doesn’t increase … My question is — is this normal to have these?
Nope. Having these hang around is not “normal”. They shouldn’t be there. But they are evidence that there is an actual connected socket behind them.
If not, has anyone got any ideas on how I can go about figuring out what’s causing them
The cause is legitimate socket connections, caused by over-eager and buggy re-connection logic inside old versions of our iPad app. An iPad could end up connecting to the server multiple times, throuhgh multiple sockets, without ever connecting to the channel as it should. So it kept trying, eventually saturating the number of allowed sockets from that device. I can’t force these users to update to the latest version of the app as some of their devices don’t support it, so I had to figure out how to solve it server-side.
and ultimately how to ensure they don’t occur?
They still occur, but I have put something in place called SocketReaper which ensures they don’t hang around for long.
It starts monitoring the socket from the socket’s init/1 function then, if the socket isn’t being used as the transport_pid inside a channel process within an appropriate amount of time, it’s killed.
It’s been in operation a few days now and is working beautifully. Hopefully this helps someone else.
3 Likes
