The issue with calendar alarms

[Bron Gondwana]

No external documentation required for this, it's changed some internal
behaviour (with comments in the related code), but as far as the user is
concerned, it just means that alarms work as they're supposed to.
Bron.


On Tue, 2 Jan 2018, at 10:37, Nicola Nye wrote:
> 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
>> 
>> 
> 

--
  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/689e3377/attachment.html>