I have a phoenix app using channels extensively and my problem is that after x number of mins when I try to send data over the channel from the client (js client in web browser), I get no response, and the app just logs the unmatched topic error/warning.
I have set the timeout on the UserSocket transport to :infinity
## Transports
transport :websocket,
Phoenix.Transports.WebSocket,
timeout: :infinity
transport :longpoll, Phoenix.Transports.LongPoll
I’m still getting the unmatched topic warning. The topic that is unmatched is the same one that connects fine at sign in, so it appears that if no data is sent after x mins the channel connection drops.
I need to be able to sign in, in a morning, and then have the WebSocket stay open all day.
I could set up a javascript timer to keep pinging the socket every 5 mins or so, but that seems hacky, is there a way to keep the socket open indefinitely?
The phoenix channels client already pings and keeps it active via a heartbeat, so if it is dying then some user code on the server or client is causing it or something between the client and server is killing the connection (proxy?).
Do you have a reproducible example and/or code with it running somewhere?
NGinx has a websocket timeout default as I recall, be sure to up it to something reasonable for what you want (24 hours or so, I think it defaults to like 10 minutes or something?)
As for that unmatched topic, that’s still odd, what’s your channel definitions in AppNameWeb.UserSocket (also how are you getting \r’s in your log file?!)?
So when I clear the Connection header, the channel stays open. I guess the client is sending ‘close’.
I’m using Elm for the client code, with an elm-phoenix package for the WebSocket handling, so it looks like it may be this package sending close(?) (which I guess answers why I was getting the unmatched topic warnings).
(The \r’s in my log file are from doing a find/replace in sublime)
It seems to be ok now (prior to fully testing all day today), thanks for the nginx tip.
Packages in the package listing are not allowed to contain javascript, which since mine used the official phoenix javascript interface means it’s not allowed to be hosted there thus it has to be grabbed from github:
Do note, mine was made for 0.16 as I recall so it might need some updating to 0.18, but the edits should be fairly minor.
I’m not in that whole camp in Elm of rewrite-the-everything-in-elm, better to use well tested things instead. ^.^;
That’s how I started out using sockets with Phoenix and Elm - I used the official phoenix js interface with my own ports in and out of Elm handling the traffic. Then I started ‘learning Elm more’ and it appeared from what I was ‘learning’ that I should move away from ports + js to pure Elm packages.
I’ve since ended up with a library of my own js modules that all do simple things well (that I find tough in Elm) and are easily tested, so I’ve gone round in a bit of a circle - but learnt things along the way .
I’ll take a look at your package over the weekend, thanks.
My package is mostly just a set of typed interfaces around phoenix channel ports, you can easily just use ports straight and custom types instead of needing to be generic as mine was too.