[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: RFC2589 implementation
> At 10:24 AM 1/2/2006, Pierangelo Masarati wrote:
>>> In regards to replication, I suggest that the master produce
>>> replication events for the deletes and the slaves simply
>>> act upon these events. Aside from allowing the use
>>> non-dynamic-entry-aware slaves,
This is contemplated: if the overlay's state is set to FALSE, it only
installs support for dynamic objects, but for the rest slapd acts as a
regular slave; the same applies to a proxy, where the inactive overlay is
simply used to install handling for the refresh exop. I think I should
split the module in two, so that the inactive overlay is not installed at
all, and only support for refresh is installed; all the rest that's needed
is to mark the database as SLAPD_DYNAMIC().
>>> it prevents replication
>>> errors caused by dynamic v. replication event ordering.
>>
>>I considered that possibility, but I didn't choose that way because if
>> the
>>master crashes the dynamic objects on the slave will never expire.
>
> Well, you could write them to the DB.
I do. I also keep a dynamic structure for the task and so.
>
>>Another point is that currently when the master shutdowns cleanly, it
>>deletes all the dynamic objects; if replica dynamic entry deletion is
>>based on replication, dynamic objects would be prematurely deleted on all
>>slaves even if only the master was stopped.
>
> If you wrote them to the DB, you could delete them on startup
> (if they have expired). To accomplish this, I'd use absolute
> time management internally and just treat the ttl stuff as
> the client visable interface.
Actually I do the opposite: entries are stored into the database, so that
regular operations don't need any special handling by the overlay; at
shutdown, dynamic objects are expunged. This should also be consistent
with RFC 2589, as clients must be ready to regenerate the entry if for any
reason the expire time cannot be honored.
>
>>I think we can handle this,
>>though; but in any case slaves must be able to account for dynamic object
>>expiration on their own; or simply, we shouldn't bother too much about
>>consistency of replicted dynamic objects.
>
> RFC 2589 was supposedly designed such that no harm would
> come from delayed deletion. Unforunately, the use of
> relative TTLs screws this over. Oh well.
I noted that issue, and in fact I make use of the task's absolute timing
any time it's required. To preserve absolute timing I think we need to
add an operational attribute that contains the expiration time. Is it
worth the effort? And I'm not absolutely sure preserving dynamic objects
across DSA reboots is consistent with RFC 2589; for sure, it would be a
nice feature. However, I'd leave it as an exercise for someone else ;).
p.
Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati@sys-net.it
------------------------------------------