Hi Jason, Thanks for the feedback. Yes, the new DNS records now have much longer TTL and are therefore more likely to be cached. I also made some subtle changes to the logic when we first attempt to connect and actually try to start writing to the cloud that might make a difference there.
/D > On Apr 19, 2021, at 1:50 PM, Jason Bramwell wrote: > > Many thanks as always. > > I used to see a ‘feature’ where the first attempt to load Subsurface would > fall back to using the local cache and i’d have to close/reopen Subsurface to > get it to connect to the cloud storage, Linux diagnosed this as likely slow > DNS lookup, very brief testing (I do mean very brief) seems to indicate that > this is no longer the save now and it ‘just works’. > > Jason > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 > > From: Dirk Hohndel via subsurface <mailto:[email protected]> > Sent: 19 April 2021 21:00 > To: Subsurface Mailing List <mailto:[email protected]> > Subject: redundant cloud servers > > > Over the past couple of weeks I quietly moved the cloud server backend and > the authentication database out of my home network and back into the public > cloud. > The fact that apparently no one noticed and nothing broke was rather > encouraging :-) > > I then setup a second cloud server in the public cloud, this one in Europe > (actually, Frankfurt, Germany). > > A few minutes ago I merged a pull request that adds a couple of interesting > new features to both Subsurface and Subsurface-mobile: > > - geo based choice of cloud server (those in the Americas should end up using > the US server, everyone else should get directed to the European server), > which is intended to be completely transparent to the user. > I.e., unless you explicitly look for it, you shouldn't notice (or care) which > server you are using > - hot failover between the two servers (so if the server that you have used > before is unavailable, Subsurface and Subsurface-mobile should try the other > one - and the implementation makes it easy to add more servers if that > appears useful) > > The two servers are automatically kept in sync in the background. I can > create one extremely artificial case where there is a fairly short (generally > sub one second in my tests) window for a race condition. A user would have to > have two different devices that are synced to different servers (for example > because they took their phone with them on an overseas dive trip), that have > made conflicting changes to the dive log, and the user would then have to > cause a save to the cloud on both devices within the roughly one second > window. Forcing that race turned out to be fairly hard because the mobile app > does a few other things before storing the data to the cloud - so for testing > I ended up using two instances of Subsurface and synchronized clicks... > really -- not a realistic scenario. > > If this were to happen, I will get an automated email alert and fixing the > problem isn't really hard - but I wanted to give a full disclosure of the > issues that I am aware of. > > What would help right now if people tested all this. > So far I have not had the time to make new beta versions of > Subsurface-mobile, but as I said, it's actually easier to test on the desktop. > > /D > _______________________________________________ > subsurface mailing list > [email protected] > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
