[PATCH] s4-drs: Store uSNUrgent for Urgent Replication
Fernando J V da Silva
fernandojvsilva at yahoo.com.br
Wed Dec 16 15:44:10 MST 2009
Hi again!
I've just fixed it. I'm going to send this patch again later this thursday.
Best Regards,
--
Fernando J V da Silva
M Sc Computer Science Student
Institute of Computing, State University of Campinas
+55 15 8801-2165
2009/12/11 Fernando J V da Silva <fernandojvsilva at yahoo.com.br>:
> Hi!
>
> I've been working on DRS Urgent Replication ToDo item
> (http://wiki.samba.org/index.php/Samba4_DRS_TODO_List#Urgent_replication)
> and I wrote a small patch which tries to follow the approach described
> by Tridge (see below).
>
>> I think to implement this we'll need some modifications to
>> repl_meta_data.c. For each modification that happens in that module,
>> we'll need to work out if it involves an urgent attribute. If it does
>> involve an urgent attribute then we need to get that information up to
>> the repl task (see dreplsrv_notify_check() in
>> dsdb/repl/drepl_notify.c).
>>
>> Probably the best way to do that is to extend the @REPLCHANGED
>> object in the root of each NC. To see these attributes with ldbsearch,
>> do something like this:
>>
>> ldbsearch -H $PREFIX/$DN.ldb -s base -b @REPLCHANGED
>>
>> where $DN is each of the naming contexts.
>>
>> currently it contains just a uSNHighest attribute, which is the
>> highest uSN of a modify to this NC. We could add a new attribute
>> uCNUrgent which will be the highest uSN of any urgent changes. Then
>> the drepl_notify.c code can work out if it should mark the
>> notification as urgent.
>
> In this initial patch, the uSNUrgent is stored when one of the objects
> mentioned in http://msdn.microsoft.com/en-us/library/dd240020(PROT.13).aspx
> are created/updated/deleted (depending on the objectclass ...).
>
> It seems that it's working correctly in a few tests that I've done
> when I was adding or modifying some of those objects/attributes, but
> it hangs on a infinite loop when I run make test...
>
> Following are more details about what I'm doing:
>
> - The implementation:
> * The replmd_check_urgent(...) function that I've created on
> repl_meta_data.c gets a ldb_message and only checks if it intends to
> update/create/delete some urgent object or update some urgent
> attribute;
> * replmd_check_urgent(...) is called inside functions like
> replmd_add(...) or replmd_modify(...) and if it indicates the need for
> urgent replication, then the callback function for the modify request
> or add request is replmd_urgent_callback instead of
> replmd_op_callback;
> * replmd_urgent_callback(...) is very similar to
> replmd_op_callback(...), but it store the partitions that need urgent
> replication on replmd_private->ncs_urg instead of replmd_private->ncs
> (perhaps there is a better approach to this task? ...);
> * uSNUrgent and uSNHighest are stored for the necessary partitions
> on replmd_notify_store(...)
>
> - The bug (infinite loop when run make test):
> * The infinite loop happens during provision, when it tries to
> create the following object (with controls relax:0):
> dn: CN=Users,DC=samba,DC=example,DC=com
> objectClass: top
> objectClass: container
> * A few other objects were created correctly before that one and it
> seems that none of those objects were among the ones whose need urgent
> replication;
> * It hangs on replmd_op_callback(...) at loop:
> for (modified_partition = replmd_private->ncs;
> modified_partition;
> modified_partition = modified_partition->next) {
> if (ldb_dn_compare(modified_partition->dn, partition->dn) == 0) {
> break;
> }
> }
> It hangs there because, for this object, we have
> modified_partition == modified_partition->next and it never leaves
> that loop.
> * The replmd_check_urgent(...) function returns false for all
> objects, but if I didn't call it when I'm adding an object, then this
> infinite loop doesn't happen (perhaps I'm doing something wrong inside
> that function so I broke the replmd_private->ncs list? I couldn't see
> anything yet ...);
> * I also tried to add a very similar object on my current
> development environment (where only the basedn was different) using
> ldbadd and it worked correctly...
>
> The patch is attached in this message and also available at
> git://repo.or.cz/Samba/fernandojvsilva.git
>
> Best regards,
>
> --
> Fernando J V da Silva
> M Sc Computer Science Student
> Institute of Computing, State University of Campinas
> +55 15 8801-2165
>
More information about the samba-technical
mailing list