The issue with calendar alarms

[Nicola Nye]

That was a nice bug!

In the event of a failover, is there human intervention required to
adjust sync mode so the old replica/new master now knows it's the boss?
Tell me about your documentation plans!


On Thu, Dec 28, 2017, at 3:02 PM, Bron Gondwana wrote:
> Calendar alarms and replication are a real problem for the
> following reason:> 
> 1) calalarmd needs to only run on the master, not the replica -
>    otherwise the alarm will fire on both, and the alarmd on the
>    replica will write annotations, causing split brain issues.> 
> 2) the caldav_alarms.sqlite3 database on the replica needs to have all
>    the nextalarm values in sync with the master, so if there's a
>    failover event, the calalarmd on the ex-replica knows which records
>    are interesting without having to parse every single mailbox!> 
> 3) replication and annotations is a disaster - the record gets written
>    first, and the annotations later.> 
> So we solve this as follows:
> 
> a) if record.silent is set, we don't write the caldav_alarms.sqlite3
>    event line for the record immediately.> 
> b) AFTER we have applied both the record and any annotations for the
>    record in sync_support.c, we call caldav_alarm_touch_record(),
>    which can then read the annotation to see when the nextalarm
>    should be.> 
> The problem is this: if there's already a nextalarm value, and we
> change a record to have an earlier alarm for whatever reason, the
> alarm annotation just gets copied by dav_store_resource to the new
> record, and hence there's already a nextalarm in the future.  This
> OVERWRITES the earlier alarm value created by
> caldav_alarm_new_record().> 
> The fix is this: instead of blindly overwriting,
> caldav_alarm_touch_record needs to have two modes: sync mode and non-
> sync mode.> 
> In sync mode, it's a replica - so it just does what it does now -
> blindly writes the value from the annotation.> 
> In non-sync mode, it instead always reads the record (plus any per-
> user overrides) and finds the time that it next needs to be checked.> 
> Easy-peasy :)  I might even just call it two different things to make
> it extra clear what's going on!> 
> Bron.
> 
> --
>   Bron Gondwana, CEO, FastMail Pty Ltd
>   brong at fastmailteam.com
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20180102/43a2e3d6/attachment.html>