On a server dedicated for development, I have noticed that although all clients connections are closed ( closed browsers tabs ), the UserSocket.connect keeps get called…
I know about the fault-tolerance feature, that clients will keep trying to connect to the server in case of connection lost, but in my case, all browser tabs that has the phoenix clients are closed, I expect that no other connection attempts will occur, however that would not happen.
Can someone explain to me? I even tried to run the server on another port number that was not used before, but still the UserSocket.connect keeps get called… so, who is calling it? how can I stop this?
Hmmm, I don’t really know but here is a very vague assumption, it could be that Phoenix itself is checking if the process is alive and working properly, for fault-tolerance reasons as you stated.
Then for example it can restart the Socket accepting process if it does not respond as expected.
Yes, I have thought of this assumption, but for how long would it keep trying to re-connect? if this assumption is correct, how would I set the reconnection attempts number?
What if I want to remove all users and start the server as a fresh start?
Each user connection is represented by its own process to keep track of the respective state.
There must be a registry of some sorts that keeps track of all these processes. So one way would be go enumerate over that list and kill each process, however I am pretty sure there is a supervisor (probably the socket process, not sure) that looks over these “client” processes and will kill them before it dies, so I think you could just find the pid or name of the socket process then send an otp message to terminate it.
Well… most likely for as long as your application is running.
There most likely is a way and it will probably be documented in the phoenix docs
:EDIT: I now realized that it seems like you are worried for connections staying open and maybe burdening down the system. I assure you that if its phoenix sending the connection requests for checkup, it will properly clean up after itself, leaving no extra baggage.
I have found that I wasn’t running the server on a different port.
Once I have started the server on a different port, and stop it, then start the server on the previous port 4000, all the reconnection attempts was stopped!
Hmmm, what is it that you are trying to accomplish or figure out? Maybe including some of the logs would make it clearer for me, as now I feel a bit confused
It could (and very likely does) use monitoring (as in the built-in from Erlang) of processes to keep track of their being up or down. You don’t need to continuously call something to know whether it’s up or not. If we had to do that we’d be in no better a situation as with other VMs and languages.
When we monitor a process in Erlang it means that we’ll be sent a message when the process dies, so that we can react to this information. Linking a process means much the same, except that it’ll instead send an exit signal to the process that it’s linked to. If that process is “trapping exits” it can turn that into a message instead.
With regards to the original problem, I’d suspect a browser of having lingering connections up more than I’d suspect anything on the server.
@sabri: Given the new information, are you still seeing any odd behaviour?
You are absolutely right, OTP all the way! I was just skeptical in case phoenix wanted to make thorough socket requests for some special reason, like a test of some sort, also thought there might be a timeout mechanism that it tried to overcome. But on second thought both of these approaches are hacky and unnecessary in the good foundations we are given with the beam vm.
Thats a pretty good suspicion! @sabri if you see that behavior again try killing the browser completely, and then make sure its dead with process (the *nix or god forbid dos kind) managing tools. It might be that killing a tab is not enough to stop the browser from keeping the connection active.
but, I don’t know why…
