2

I'm building an Android application using Cloud Firestore. Specifically I use live subscription (Snapshot Listener). And noticed a strange behavior.

When internet connection is lost, eventually, I cannot get any data from Firestore (considering it's offline cache is empty). When connection is back, I'm still not getting any data for 30-50 seconds. And only after that, quite long period of time, Firestore serves the data again.

Any ideas where this latency comes from and how to deal with it? It's really annoying.

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
Max S
  • 23
  • 4
  • If you have solid, detailed reproduction steps, consider filing a bug report. https://firebase.google.com/support/contact/bugs-features/ – Doug Stevenson Jul 05 '18 at 16:48

1 Answers1

0

While the device is offline and if you have enabled offline persistence (which in Firestore is enabled by default), your listeners will receive listen events when the locally cached data changes. The first time you attach a listener, Firestore will access the network to download all of the results of your query and provide you a QuerySnapshot object. If you attach the same listener, the second time and you're using offline persistence, the listener will be fired immediately with the results from the cache. After you get the cached result, Firestore will check with the server to see if there are any changes to your query result. If yes you will get another snapshot with the changes.

Note, if you are using a get() call, Firestore will still try to hit the network first, to give you as up-to-date data as possible. If you use addSnapshotListener() instead, Firestore will call you immediately with the cached data, without waiting for the network. That's why you have that ammount of time between the time that you are getting back online and the actual synchronization.

You can also take a look on my answer for this post.

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
  • Alex, thanks for your reply! However I described a bit different situation and stated that cache is empty. Imagine that I'm trying to access FS servers for the first time with no internet connection. I get nothing, so cache is empty as well, which is perfectly as expected. I then switch the connection back on and again request data from FS. As soon as I now have connection I expect FS to fetch the data and serve it for me. However, this is not the case. FS still returns nothing for another 30-50 seconds... – Max S Jul 05 '18 at 09:21
  • If you are speaking abot the first atempt to read documents from the database, it might be slower than the subsequent ones, because it has to initiate the internet connection. For the second time, it's normal behaviour, because you are using `addSnapshotListener()`. If you want to get the data right away, use a `get()` call. – Alex Mamo Jul 05 '18 at 09:35
  • Please also note, that when you get back online, the Firebase SDK will attempt to restore the websocket it uses to communicate with the server. This websocket is fully managed by the SDK. You don't have to do anything to tell it to reconnect. – Alex Mamo Jul 05 '18 at 09:39
  • In case I'm describing get() takes the same time (up to 1 min) to reconnect and serve the data. Subsequent calls are much faster. I understand internet connection has to be initialized. But latency up to 1 min is just ridiculous. – Max S Jul 05 '18 at 09:48
  • Please take a look also **[here](https://stackoverflow.com/questions/48863393/firebase-listeners-first-time-invocation-takes-time)**. – Alex Mamo Jul 05 '18 at 10:22
  • Is there everything alright? Can I help you with other informations? – Alex Mamo Jul 06 '18 at 06:36
  • Hi, Alex! The problem is still there. Thanks for your help. I'll try to file a bug to Google. – Max S Jul 06 '18 at 07:53
  • Ok, keep me posted. – Alex Mamo Jul 06 '18 at 07:56
  • Ok, keep me posted but I think that in this case is likely just the socket time-out on your device. There is nothing the Firebase client can do about that, as it's a normal part of the operation of sockets. – Alex Mamo Jul 06 '18 at 08:29
  • I have the same issue firestore 17.1.2. The networks comes back between 110 and 120 seconds. – François MARTIN Nov 07 '18 at 19:49
  • @FrançoisMARTIN Might be from the exact same reason. – Alex Mamo Nov 07 '18 at 19:51
  • @AlexMamo is there any way to reduce the socket time-out ? Firestore rely on gRPC that does not make it configurable. Once the stream is in a "broken" state (during ~110 seconds), there is no way to retry the request. – François MARTIN Nov 08 '18 at 20:10
  • @FrançoisMARTIN I think you should ask a fresh new question. – Alex Mamo Nov 08 '18 at 20:12
  • @FrançoisMARTIN did you solve somehow ~120 seconds timeout problem? – Artur Eshenbrener Nov 27 '18 at 09:11
  • After discussion with the Google team, they suggest using this branch of firestore : https://github.com/firebase/firebase-android-sdk/commits/rsgowman/keepalive. This solve the problem, and might be merged into master in the next few months. You can even choose shorter keepAlive values (like 20 and 10 seconds). – François MARTIN Nov 27 '18 at 17:25