On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ondřej Kuzník wrote: > It's becoming untenable how a plain refresh cannot be represented in > accesslog in a way that's capable of serving a deltasync session. > Whatever happens, we have lost a fair amount of information to run a > proper deltasync yet if we don't want to abandon this functionality, we > have to try and fill some in.
Now for proposal 3. Most of the work is at the provider again: If a consumer gets into a plain refresh, they pass that information down in such a way that accesslog (and its syncprov) gets to find out. If a syncprov sees this message, they will end running sessions with e-syncRefreshRequired, having them fall back to a plain refresh too. Accesslog also needs to record this (and the finalisation of that refresh) in some way that also makes future consumers understand that they (don't) need to fall back into plain, even in the case of connection loss or other malfunction. This accesslog message also acts like a poison that spreads through the cluster, eventually all members will end up in plain refreshes. Taking this approach requires a design that is guaranteed to upgrade everyone back into a regular deltasync in a timely manner. One possible approach might include an idea floated in the other proposals where we have the provider commit to a CSN that refresh will end with and commit that as a time limit on the poison we recorded into our accesslog. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
