Can't keep connection up, seemingly different errors every now and then about swiftphoenixclient HOT 9 CLOSED

Thanks for reporting @simpers. Let me know if you get any more errors. I'll look into this and see what else I can find.

from swiftphoenixclient.

@dsrees I have a few ideas of what's up.

Either the server is misconfigured, but I do not know what that would be as I have left it all at the defaults (I think) and just implemented 3 channels, currently.

Or there is an iOS-thing that causes this to happen because of a behaviour that is happening inside SwiftPhoenixClient, as I keep getting some weird behaviour regarding the sockets themselves, where I sometimes get errors from the TCP layer suggesting something is wrong on that layer.

Or it is an error with the implementation of the Phoenix Client. I did however also try another client called Birdsong, and it also behaves in this same way, albeit has less debugging information so if I'd use that I would only have a 'disconnected' message, if even that.

So I am wondering if it is the server or not. Which Phoenix version do you support? Is there a way to change the channel protocol from 1.0 upward? I read something about Phoenix having a WebsocketSerializer which you can decide to support a minimum version of, or something.

Which Erlang/OTP version is necessary for all of this to work? If you have any data on this yourself I'd love to hear some. I'll try to create a minimal app example doing the same thing (it just shows events in a ViewController currently) to see if it occurs there as well, or if it is a project specific problem of my iOS app.

from swiftphoenixclient.

@simpers Thanks for all of that! My initial thought is that it is server side. The Socket is closing with a 1000 code which means it was closed successfully. However that could also be the case if the client requested it be closed.

The client should be reattempting a connection if it was closed due to an error. It won't attempt to reconnect if the client or the server closed the connection (at least, that's how it is supposed to work. There may be a bug) Because you're not getting re-connect attempts, my thought is that something is going on here.

If you could, try spinning up the demo server and point your app to that and see if you're still getting disconnects.

The client is built to work with the latest phoenix version. There currently is not a way to change the configuration to work with different versions of Phoenix.

from swiftphoenixclient.

@dsrees I think it might have been this:
timeout: 30_000

I guess depending on the exact timing of this timeout, seeing as the heartbeat also seems to be 30 seconds, that might have caused the random disconnects.

I think I copied all of this when I tried to solve the check_origin: false in order to allow connections from the iPad earlier.

transport :websocket Phoenix.Transports.Websocket,
    timeout: 30_000,
    serializer: [ { Phoenix.Transports.WebSocketSerializer, "~> 1.0.0" } ],
    check_origin: false

I have removed it to see if it helps and it looks promising. However, is there no way to change the default heartbeat timer of the client?

But how come it is registered as an error? I tried to implement some reconnection logic due to all of this, seeing as it didn't automatically do that even though I set it to (which you answered by saying it doesn't because it's a normal close of the socket), but it fails the reconnect with an actual error. Do I need to create an entirely new socket or something after a successful closure of the socket?

I also wonder what that serializer is for, which is what I referred to in my previous comment I think.

from swiftphoenixclient.

Good find! You can change the heartbeat interval

let socket = Socket()
socket.heartbeatIntervalMs = 20000 // 20s heartbeat

You can also disable it

socket.skipHeartbeat = true

See more here

I'll have to look into the reconnect logic. There may be something out of place

from swiftphoenixclient.

I'll experiment a bit locally with that setting then.

I guess what really confused me and got me pulling my hair was that it was logged as an error and indicated that something was broken, when it in fact as you say was behaving correctly. The only weird thing was that it was recorded as an error so I tried to fix it somehow and started looking in the wrong place.

from swiftphoenixclient.

@simpers - any result on this? I'm seeing similar issues (#122), but only on our staging server... Were you able to resolve it on your end?

from swiftphoenixclient.

@astjohn The error was that a misconfiguration on the server (timeout was set to 30 seconds, and the heartbeat was exactly 30 seconds as well, so sometimes it failed, sometimes not) resulted in an error on the client. So I thought something else was wrong, but I think we came to the conclusion that it behaved correctly. I just bumped the 30 seconds to something higher and it has worked after that.

from swiftphoenixclient.

@astjohn @simpers Glad you were both able to resolve this by adjusting the server timeout.

from swiftphoenixclient.