Client connections when internet lost

[rakirox]

Hi there, I have found an issue.

I am trying to handle all my internet connections handlers, reconnections and disconnections. The meteor handlers works just find OnDiscconnected and onException etc.

My approach right now to reconnect once the internet is back (without having a broadcast from android telling me the internet state). Is the next one:

@Override public void onDisconnect() { Log.e("gotDisconnected","well..."); mMeteor.reconnect(); }

and it works well, it gets reconnect but the problem is that all web sockets that tried to connect while the internet was off are getting connected.

    /**
    * Opens a connection to the server over websocket
    *
    * @param isReconnect whether this is a re-connect attempt or not
    */
    private void openConnection(final boolean isReconnect) {
            if (isReconnect) {
                    if (mConnected) {
                            initConnection(mSessionID);
                            return;
                    }
            }

    // create a new WebSocket connection for the data transfer
    mWebSocket = new WebSocket(URI.create(mServerUri));

    // attach the handler to the connection
    mWebSocket.setEventHandler(mWebSocketEventHandler);

    try {
        mWebSocket.connect();
    }
    catch (WebSocketException e) {
        mCallbackProxy.onException(e);
    }
}

first I saw at my galaxy dashboard that my server was getting 100+ clients when I'm the only one running tests. Then on my log I found a lot of exceptions after my internet was reestablished.

:remote E/METEOR EXCEPTION: unknown host: wagen.meteorapp.com
:remote E/gotDisconnected: well...
:remote E/METEOR EXCEPTION: error while sending data: not connected
:remote E/data removed: kadira_settings
:remote E/info: {"emails":[{"address":"some@email.com","verified":true}],"profile":{"name":"Carlos Palmero","type":"Driver","boss":"p4QQGew7EqbYr4TWg","connection":true,"currentStatus":1,"statusStack":[{"status":{"name":"Solving Ticket","description":"When the driver has arrived and start doing the service","color":"#6600cc"},"timeStamp":{"$date":1463417312821}},{"status":{"name":"On Service","description":"When the driver has started his service","color":"#00ff00"},"timeStamp":{"$date":1463418509087}},{"status":{"name":"Solving Ticket","description":"When the driver has arrived and start doing the service","color":"#6600cc"},"timeStamp":{"$date":1463422746940}}]}}
:remote E/gotConnected: is signed in?yep
:remote E/data removed: kadira_settings
:remote E/METEOR EXCEPTION: IO Error
:remote E/gotDisconnected: well...
:remote E/METEOR EXCEPTION: IO Exception
:remote E/data removed: kadira_settings
:remote E/info: {"emails":[{"address":"some@email.com","verified":true}],"profile":{"name":"Carlos Palmero","type":"Driver","boss":"p4QQGew7EqbYr4TWg","connection":true,"currentStatus":1,"statusStack":[{"status":{"name":"Solving Ticket","description":"When the driver has arrived and start doing the service","color":"#6600cc"},"timeStamp":{"$date":1463417312821}},{"status":{"name":"On Service","description":"When the driver has started his service","color":"#00ff00"},"timeStamp":{"$date":1463418509087}},{"status":{"name":"Solving Ticket","description":"When the driver has arrived and start doing the service","color":"#6600cc"},"timeStamp":{"$date":1463422746940}}]}}
:remote E/gotConnected: is signed in?yep
:remote E/data removed: kadira_settings
:remote E/gotDisconnected: well...
:remote E/METEOR EXCEPTION: error while sending data: not connected
:remote E/data removed: kadira_settings
:remote E/info: {"emails":[{"address":"some@email.com","verified":true}],"profile":{"name":"Carlos Palmero","type":"Driver","boss":"p4QQGew7EqbYr4TWg","connection":true,"currentStatus":1,"statusStack":[{"status":{"name":"Solving Ticket","description":"When the driver has arrived and start doing the service","color":"#6600cc"},"timeStamp":{"$date":1463417312821}},{"status":{"name":"On Service","description":"When the driver has started his service","color":"#00ff00"},"timeStamp":{"$date":1463418509087}},{"status":{"name":"Solving Ticket","description":"When the driver has arrived and start doing the service","color":"#6600cc"},"timeStamp":{"$date":1463422746940}}]}}
:remote E/gotConnected: is signed in?yep
:remote E/data removed: kadira_settings

and after I force quit it this displayed at Log:

E/METEOR EXCEPTION: Connection closed before handshake was complete

a lot of times btw

[ocram]

Thanks for your report!

There's a built-in solution for automatic re-connecting, as you have seen. Not sure if that plays well with your (additional) custom mechanism for the re-connects. What do you think?

Could you disable one of the two solutions? What about the internal solution only? Does it work or is there anything wrong with it so that you had to create a custom solution?

[rakirox]

Is this what you mean?
#89
in this approach I see that it only tries n times which is good only in fast disconnections and reconnections.

But as far as I see what would happen when it have exceded the max amount?
It won't reconnect. It should have an internet status listener. perhaps a receiver to the broadcast "android.net.wifi.WIFI_STATE_CHANGED" am I right?
<receiver android:name=".services.InternetConnectionReciver"> <intent-filter> <action android:name="android.net.conn.CONNECTIVITY_CHANGE" /> <action android:name="android.net.wifi.WIFI_STATE_CHANGED" /> </intent-filter> </receiver>
I'll try to achieve this

[rakirox]

but even if I do the approach I wrote in the last post, when I try to reconnect on the second time it will be keep the last connection making 2 client when reconnecting or 3 clients if it happens again. that's why I refer when I say that I found an issue or in other words a bug...

[ocram]

Yes, the issue that you referenced does list what has to be improved. But nevertheless, the automatic re-connect should work today.

Using the connectivity state to make re-connects more efficient is a good idea. Let's track the progress of this issue here: #98

Can you try the built-in mechanism for re-connects and (temporarily) disable your own implementation? What's wrong with the built-in solution? Yes, there may be some issues that we have to fix, but what's preventing it from working for you today, specifically?

[rakirox]

The built-in reconnections works just fine ( just for those fast reconnections). My poor implementation (of reconnections) right know is just to avoid doing the broadcast receiver (just to run some tests fast).
What's preventing me to work is the N connections (bug made for each web socket created) that are made and breaks my galaxy server.

I implemented a simple solution, which as far as I see it's preventing from doing a lot of clients.
but after it reconnects it seems that my subscriptions are not longer alive. I can do some Meteor.calls and works just fine but I'm not retrieving my data's updates.

[rakirox]

@mwaclawek any idea? about the subscriptions

[ocram]

It seems your pull request #99 solved the problem of too many clients connected to the server for you, right? Before, there was one client and after it re-connected there were two clients. Now there is one client and after re-connecting, the old one goes away so that there is still only one client. Is this correct? If it is, we have fixed this problem.

Then there seems to be another problem, i.e. subcriptions not sending any data after a re-connect. Is this correct as well? The most important question is: Do the subscriptions stop working after re-connects only with your pull request #99 added to the code or does this happen after re-connects with the current stable version of this library as well?

[niketaB]

I am facing same issue. Can anybody help me to solve this please ?
I am using the latest revision.