Phoenix Socket draining

There is an example on how to close a channel (i.e. websocket) server-side in the docs (Phoenix.Socket — Phoenix v1.8.8)

MyAppWeb.Endpoint.broadcast("users_socket:" <> user.id, "disconnect", %{})

But AFAICS it always needs those ids, which you could gather using presence track which keeps its updates (presence_diff) private.

On a shutdown signal you could iterate these ids and broadcast that above disconnect to your sockets.

In one of the projects we use SocketDrano — socket_drano v0.6.0, though personally I haven’t worked with it yet so, can’t provide details

That’s handy, thanks!

From the docs:

Important: This library currently leverages an undocumented internal function in Phoenix to achieve its magic of closing local sockets.

But if we’re running in a cluster, Presence will return a global list correct, not just the locally connected sockets.

We could probably do some other form of local bookkeeping with say a Registry, but I was hoping to avoid that…

Presence.track can store key/values so you could store hostname and userid? So on a quit signal do a lookup on hostname and you have a list of connected sockets for that node? And you could use Phoenix.PubSub — Phoenix.PubSub v2.2.0 to keep the broadcast local to the node.

We’ve come up with a not-so-great workaround for now.

SocketDrano had a couple issues for us:

• it relied on channel join telemetry events, so it would miss sockets that do not join a channel
• it was oriented around draining upon sigterm, but we’re relying on CodeDeploy lifecycle events for triggering the draining

So, we ended up “extending” Phoenix.Socket by creating our own Socket module that has overrideable callbacks:

Then we create a custom init callback:

@impl Phoenix.Socket.Transport
   def init(state) do
     super(state)
     |> tap(fn
       {:ok, {_state, %Phoenix.Socket{transport_pid: pid}}} when is_pid(pid) ->
         track_socket(pid)

       _ ->
         :ok
     end)
   end

track_socket then does essentially what SocketDrano does (monitor the socket pids, disconnects them when told to).

I’ve opened a thread on the Phoenix Core mailing list asking about better solutions being added Phoenix itself: https://groups.google.com/g/phoenix-core/c/1umhh2X1oAM/m/_sfxU8xIBgAJ

just an off topic to connection draining, why are you using ALB when they are not guaranteed to maintain persistent connections, NLB is recommended for persistent connections. Do you guys see any connection issue with ALB or just not at the scale where you ALB would scale out/in in the background for you to drop connections

Sorry to ask but I have no clue of what ALB and NLB means, but I would guess that is something related with load balancing.

AWS Application Load Balancer (L7) and Network Load Balancer (L4)

For folks coming across this recently: Phoenix sockets now have built-in connection draining (since 1.7.2). You can configure it with the drainer option to socket/3: Phoenix.Endpoint — Phoenix v1.8.8