For now, WebSocketListener class in WebSocketSubscriptionTransport.java, just notify upper level when on failure. When on closed, it just release, and notify nothing. So if the websocket server close the connection, client will lost the subscription forever, and don't know when to resubscribe. Please fix it, thanks!
Going to take look into this issue. Logged something similar here: https://github.com/apollographql/apollo-android/issues/1003
@wtrocki Your solution is to solve the problem when there are network exceptions, but I mean for such scenario: you subscribe a subscription, but the server engineer fix some bug or implement some new requirement, he has to restart the server in the deployment process. Because it's a restart, the server will first close the connection normally, and then start again. So there is no network exception. I thought apollo-android should send notification to upper level, but auto-reconnection is ok either. I have test the react-apollo implementation for this, it auto reconnects the server even the server closes the connection normally. If auto-reconnection is implemented, notification is unnecessary. I like your idea too.
@wtrocki @digitalbuddha @khejing there are 2 approaches I see how to address this issue:
com.apollographql.apollo.internal.subscription.SubscriptionManager.Callback like onClosedApolloSubscriptionException like ApolloSubscriptionInterruptedException that will indicate server closed connection without any notice (initiated by the sever without sending complete message).Any thoughts?
Hello! Is there any solution for this? Thank you!
I went with the path of having onClosed() method in callback. This however had some side effects on multiple subscriptions - need to resubscribe manually on error. Going this path did not resolved problem as it was just covering single subscription when problems are usually related with global subscription manager backed by websockets connection that is being closed.
I spent some time debugging this under various network conditions and found websockets having problems with slow mobile networks. Technically your device can be connected to internet, but websockets connections will still fail.
I found application level solution that were too specific to contribute upstream. In my case subscriptions are used to refuel local state ( cache) rather than specific Views. I just wrote my own subscription transport that has all subscriptions on startup and link that with queries. This way I can avoid memory leaks and have one centralized place for holding state where I interact with my cache layer, however this is not something that should land into upstream.
What I love in Apollo is that their SDK architecture allows to swap implementations so if something is not working I can always override behaviour to code that makes sense for my use case.
I believe that there is a way to know that websockets were disconnected but weren't particularly convinced that this needs to be done for every subscription callback. Extending subscription transport will give unlimited possibilities that can be adjusted for business use cases.
Note: I'm not associated with Apollo team.
Actually auto reconection could be good upstream solution for those problems. Problem with that aproach is to see when reconnection can happen and this is really hard to generalize. Relying on offline online state will not be enough as server can go down as well etc.
@Dragons0458 For now, I call subscriptionTransportFactory() to get websocket events. When websocket is closing, I call apolloClient.subscriptionManager.disconnect() by using reflection, and then dispose the subscription. After that, I resubscribe it again.
@khejing Really strange that this is needed as RealSubscriptionManager already does that:
https://github.com/apollographql/apollo-android/blob/master/apollo-runtime/src/main/java/com/apollographql/apollo/internal/subscription/RealSubscriptionManager.java#L369
The only feature that is missing is reconnect.
Why is reconnection difficult? I implemented an Apollo link in Nativescript, and my way of reconnecting was that when it closed it would send the connection message again until the server answered something, or does that generate a problem? for the moment I am using the solution that @khejing (Thank you!) give me, but it seems to me that reconnection is necessary, thank you very much!
Most helpful comment
Actually auto reconection could be good upstream solution for those problems. Problem with that aproach is to see when reconnection can happen and this is really hard to generalize. Relying on offline online state will not be enough as server can go down as well etc.