60 seconds of inactivity timesout, but the connect callback isn't called to change status

[akarelas]

With websockets, if there's absolutely no traffic for 60 seconds then the connection gets dropped, and I think that's caused by Strophe, not the XMPP server, am I right?

In either case, I don't see my Strophe connection's callback get called, despite the fact that the connection's status changed (so I would need to update the browser's display).

But maybe it's the server that's doing it, and it's dropping the connection so silently that Strophe doesn't notice.

Is that the case? Please advise.

Similarly, I tried stopping my server process completely, so obviously the Strophe client must have disconnected, yet connect's callback wasn't called. Is it because Strophe doesn't want the connection to be deemed as closed just because of a temporary disconnect?

If that's the case, how do I configure Strophe to consider websocket disconnect as a disconnect from the server? Because that's how I've configured my server (a temporary disconnect will close the session).

Also, how do I configure how much time needs to pass before Strophe considers a connection as disconnected?

Also, how do I change the 60-seconds timeout duration?

[akarelas]

After some console.log's I discovered that the connection object became null, without having passed from DISCONNECTED state first. That's bad, because I wanted the DISCONNECTED state in order to launch a "reconnect" timeout.

[akarelas]

I think this is a bug. It looks like one anyway.

[Gordin]

When you use WebSockets Strophe actually doesn't use any kind of timeout, the connection should just stay open if there is no traffic, so I think your server does the timeout-thingy.

I've used Prosody while developing WebSocket support and if I shut it down while being connected this happens:

WebSocket stream error: system-shutdown - Received SIGTERM
Status change: ERROR
_doDisconnect was called
WebSockets _doDisconnect was called
Status change: DISCONNECTED
Websocket closed

This is what should happen, the StreamError basically bypasses the DISCONNECTING stage because at this point there is no connection any more to gracefully disconnect. In case of a StreamError, Strophe goes directly to the DISCONNECTED stage because of this.

However if I SIGKILL my XMPP server though I just get

Websocket closed

You're right about this being a bug, it should go to DISCONNECTED, I'll look into this. Though this only happens if the XMPP Server crashes or does not handle WebSocket connections right. Which XMPP Server (and/or WebSocket Proxy) are you using?
edit: it should go to DISCONNECTED, not DISCONNECTING

[akarelas]

I'm using my own Jabber server, KJabberd, that has an embedded Websocket listener, and which is not-yet-released, neither is it production-ready. I use Ubic to launch/stop it (I think Ubic sends SIGKILL). I'm very glad you managed to reproduce the bug. Other than this, I've had zero problems with Strophe over webcoskets. When you fix this, it will be great. Thanks.

[akarelas]

Actually the maker of ubic just told me that it sends SIGTERM, and after 10 seconds if that had failed it also sends a SIGKILL.

[akarelas]

In my case I didn't have to wait more than 1 second, so SIGTERM worked (Strophe didn't "get" the disconnection though). Of course it's my job as maker of KJabberd to process SIGTERM properly, however it would be nice if Strophe got into DISCONNECTED state even after a server crash (which could in theory happen).

[Gordin]

The status not being set on a killed WebSocket connection should be fixed now. I think kjabberd does not handle WebSocket connections right. If you shut the server down in should at least send a streamerror to connected clients. What you describe sounds like your server doesn't do that.

[akarelas]

I am going to fix this on KJabberd. There is plenty of such little stuff that needs to be done.

[akarelas]

The 60 seconds timeout was nginx's problem. And why is this bug not closed yet?