[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



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?