Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Websocket not closed on disconnect, _doDisconnect called multiple times #4

Open
MajorFailz opened this issue Jul 3, 2013 · 5 comments
Assignees
Labels

Comments

@MajorFailz
Copy link

When a Websocket connection is opened, then disconnected, after it sends the end of stream messages and so on it seems to just stop and not close the socket, this makes the _doDisconnectTimeout method fire. However after that is done it also fires multiple _doDisconnect calls that interferes with reconnection.

My code attempts to connect to the server again if the connection is disconnected, however after it starts attempting to connect the _doDisconnect is fired again which causes a socket exception complaining that you can't shut the socket before it's been opened. I have pasted my console output below and removed urls/commented where needed:

Server (1): Disconnect called
Server (1): Connection destablished callback
Server (1): Disconnecting...
Strophe: Disconnect was called because: Disconnect method was called.
LONG PAUSE
Strophe: _onDisconnectTimeout was called
Strophe: _doDisconnect was called
Server (1): Disconnected from server.
Server (1): Connect called
Server (1): Connecting to MY_WS_URL...
Strophe: _doDisconnect was called
EXCEPTION START
WebSocket connection to 'MY_WS_URL' failed: WebSocket is closed before the connection is established. /pages/chat/js/lib/strophejs-websocket/strophe.js
Strophe.Websocket._doDisconnect strophe.js:4683
Strophe.Connection._doDisconnect strophe.js:2843
Strophe.Websocket._onClose strophe.js:4706
EXCEPTION END
Strophe: _doDisconnect was called

@ghost ghost assigned Gordin Jul 3, 2013
@Gordin
Copy link
Owner

Gordin commented Jul 3, 2013

Could you test if this branch https://github.com/Gordin/strophejs/tree/disconnect-fix fixes the problem for you?

@MajorFailz
Copy link
Author

Heyup, fraid not, it appears to be moving beyond the disconnecting stage now but it is still firing multiple _doDisconnect calls that are breaking the reconnecting, here is my console output:

chat.getServerList().getServer(1).disconnect();
Server (1): Disconnect called core.js:662
Server (1): Connection destablished callback core.js:687
Server (1): Disconnecting... core.js:687
ConvoList: TODO close all convos core.js:662
Strophe: Disconnect was called because: Disconnect method was called. core.js:687
Strophe: _doDisconnect was called core.js:687
Server (1): Disconnected from server. core.js:687
Server (1): Connect called core.js:662
Server (1): Connecting to MY_WS_URL... core.js:687
undefined
Strophe: _doDisconnect was called core.js:687
WebSocket connection to 'MY_WS_URL' failed: WebSocket is closed before the connection is established. /js/lib/strophejs-disconnect-fix/strophe.js
Strophe: _doDisconnect was called core.js:687
Strophe: _doDisconnect was called

And without reconnection code:

Server (1): Disconnect called core.js:662
Server (1): Connection destablished callback core.js:687
Server (1): Disconnecting... core.js:687
ConvoList: TODO close all convos core.js:662
Strophe: Disconnect was called because: Disconnect method was called. core.js:687
Strophe: _doDisconnect was called core.js:687
Server (1): Disconnected from server. core.js:687
undefined
Strophe: _doDisconnect was called core.js:687
Strophe: _doDisconnect was called core.js:687

It seems to call _doDisconnect three times =/

P.s. thanks for being so quick to respond to these issues :)

@Gordin
Copy link
Owner

Gordin commented Jul 13, 2013

Could you give me some code to replicate this? I've tried to do it myself but in my tests the _doDisconnect in core and websockts is only called once and also reconnecting works for me.

@MajorFailz
Copy link
Author

//On connection disconnected
case Strophe.Status.DISCONNECTED:

            //Log info
            this._getLogger().info('Disconnected from server.');

            //Reset connection object
            this.getConnection().reset();

            //If this is enabled
            if(this.isEnabled())
            {
                //Execute reconnect
                this.connect(); (connects using strophe connection)
            }

            //Break from switch
            break;

As far as I can tell it's no longer doing multiple disconnect attempts (using latest code) but if you reconnect in the above manner I still get the websocket error, as if it's been force closed. Chances are I'll put in a brief timeout between connection attempts which seems to fix the problem but the above code still results in this:

Server (1): Disconnect called core.js:685
Server (1): Connection destablished callback core.js:710
Server (1): Disconnecting... core.js:710
Server (1): Disconnected from server. core.js:710
Server (1): Connect called core.js:685
Server (1): Connecting to MY CONNECTION URL... core.js:710
WebSocket connection to 'MY CONNECTION URL' failed: WebSocket is closed before the connection is established. MY CONNECTION URL/pages/chat/js/lib/strophejs-websocket-new/strophe.js
(Stack trace)
Strophe.Websocket._closeSocket strophe.js:4704
Strophe.Websocket._doDisconnect strophe.js:4693
Strophe.Connection._doDisconnect strophe.js:2849
Strophe.Websocket._onMessage strophe.js:4807

However, just tested this on Firefox and received no errors it might be browser specific. I've been using Chrome (v 27.0.1453.116) on Windows 7 for development.

@Gordin
Copy link
Owner

Gordin commented Jul 15, 2013

I actually never tried the reset thing much, but I just tested with

if (status === Strophe.Status.DISCONNECTED) {
    Peek.connection.reset();
    return Peek.connection.connect("gordin@localhost", "gordin");

which should have the least time in between reset and connect on both chrome and firefox and I'm not getting any errors and the connection is established as it should. (I'm using Chrome 28 though, that's probably not it but maybe they fixed some WebSocket handling in 28?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants