Thank you, it works nicely again.
-- Attilla
On April 24, 2021 22:22:47 Dirk Hohndel <[email protected]> wrote:
Yes, the US server VM ran out of memory and killed a process that didn't
have an auto-restart in its systemd service file...
Should be up and running again.
Those who used the latest master SHOULD have been automatically redirected
to the European server which continued working :-)
/D
On Apr 24, 2021, at 11:54 AM, Attilla de Groot <[email protected]> wrote:
Hi Dirk,
Are there any issues with the backend today? I’m not able to sync either
from my desktop or mobile (also over 4G).
— Attilla
On 19 Apr 2021, at 22:58, Dirk Hohndel via subsurface
<[email protected]> wrote:
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 for Windows 10
From: Dirk Hohndel via subsurface
Sent: 19 April 2021 21:00
To: Subsurface Mailing List
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
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
