Re: (ITS#4626) "glue" objectclass in syncrepl consumer

[hyc@symas.com]

ahasenack@terra.com.br wrote:
> On Tue, Aug 01, 2006 at 08:41:06PM +0000, ahasenack@terra.com.br wrote:
>   
>> On Mon, Jul 31, 2006 at 06:37:32PM +0000, ahasenack@terra.com.br wrote:
>>     
>>> (a) one database, one syncprov:
>>>
>>>              + dc=example,dc=com
>>>             / \
>>>          ...   + ou=global
>>>               / \
>>>            ...   ...
>>>
>>>
>>> (b)
>>>              + dc=example,dc=com
>>>             / \
>>>          ...   + ou=global (pulled from (a) via syncrepl)
>>>               / \
>>>            ...   ...
>>>
>>> This is two databases glued together: one for dc=example,dc=com and another for
>>> ou=global, which is pulled from (a) using ou=global,dc=example,dc=com as the
>>> base. I tried with one syncprov in dc=example,dc=com loaded after glue, and
>>> with two syncprov (one for each database).
>>>
>>>
>>> (c)
>>>
>>>               + dc=example,dc=com
>>>              / \
>>>           ...   + ou=global
>>>                / \
>>>             ...   ...
>>>
>>> This one is a single database and a consumer from (b). The syncrepl base is
>>> dc=example,dc=com. It's a backup server for (b).
>>>
>>> This server doesn't get changes done to ou=global, and it also has the issue
>>> where the ou=global entry itself gets mangled.
>>>       
>> The replication problem to (c) still happens with 2.3.25. Sometimes it doesn't
>> get the changes to ou=global, and sometimes it doesn't get the changes done to
>> the other database in (b). And also only sometimes restarting (c) makes it up
>> to sync again: usually the only way is to wipe out its database completely and
>> start blank.
>>     
>
> This still happens with 2.3.25cvs (REL_ENG_2_3 checked out a few hours
> ago). The "ou=global" entry gets the glue objectClass.
>
> It's very similar to what was described here about an year ago:
> http://www.openldap.org/lists/openldap-software/200508/msg00141.html
>
> I don't have any filter specified in any consumer, so it should fetch
> the whole thing. I managed, however, to sometimes get the ou=global
> entry correctly, i.e., without the glue objectClass. So a race condition
> perhaps? Ordering of results?
>   

Ordering maybe.  But eventually the entry should get replicated, and the 
consumer should replace everything with the correct objectclasses. I 
guess there's a possibility that we're not setting the right flags to 
allow the consumer to change the entry's structuralObjectClass.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/