Replication stops working due to objectClass=glue

[frank.offermanns@caseris.de]

Hi,

I have a synrepl-master and one slave.
I delete both databases and do a slapadd on the master. 
After doing so I start the slave. 
Our system has a few dozen processes changing values every minute, so they 
also do it when the inital replication is running.

>From time to time replication stops working while doing the initial 
replication.
It then always has problems with the values being edited while the intial 
replication is running (full replication needs a few minutes).

Here's a quote concerning master/master.
"Both servers will initialize their accesslogs separately from 
their main DB since they are empty, and the two logs will have different 
timestamps. You need to make sure that the main DB and log DB are 
initialized 
together on at least one of the servers."

But this quote should not count for master/slave, does it?

If replication works I have slavelogentrys like this:
30.03.2012 11:40:24 4f757f88 oc_check_required entry 
(ou=Trinity64.ub2.cae.local,ou=SystemStatus,o=caesar), objectClass 
"Server"

If it fails the objectClass is "glue"
30.03.2012 11:25:23 4f757c03 bdb_modify_internal: 0x000006af: 
ou=Trinity64.ub2.cae.local,ou=SystemStatus,o=caesar
30.03.2012 11:25:23 4f757c03 oc_check_required entry 
(ou=Trinity64.ub2.cae.local,ou=SystemStatus,o=caesar), objectClass "glue"
30.03.2012 11:25:23 4f757c03 oc_check_allowed type "structuralObjectClass"
30.03.2012 11:25:23 4f757c03 oc_check_allowed type "objectClass"
30.03.2012 11:25:23 4f757c03 oc_check_allowed type "entryUUID"
30.03.2012 11:25:23 4f757c03 oc_check_allowed type "creatorsName"
30.03.2012 11:25:23 4f757c03 oc_check_allowed type "createTimestamp"
30.03.2012 11:25:23 4f757c03 oc_check_allowed type 
"LastModifiedApplication"
30.03.2012 11:25:23 4f757c03 Entry 
(ou=Trinity64.ub2.cae.local,ou=SystemStatus,o=caesar), attribute 
'LastModifiedApplication' not allowed
30.03.2012 11:25:23 4f757c03 entry failed schema check: attribute 
'LastModifiedApplication' not allowed
30.03.2012 11:25:23 4f757c03 hdb_modify: modify failed (65)
30.03.2012 11:25:23 4f757c03 send_ldap_result: conn=-1 op=0 p=3
30.03.2012 11:25:23 4f757c03 null_callback : error code 0x41
30.03.2012 11:25:23 4f757c03 syncrepl_message_to_op: rid=001 be_modify 
ou=Trinity64.ub2.cae.local,ou=SystemStatus,o=caesar (65)

According to post:
http://www.openldap.org/lists/openldap-bugs/200608/msg00044.html
"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."

there has been a possible problem here. Is this fixed?

Version is 2.4.30, Berkeley DB 5.1 using hdb and OS is Windows.
If I should post my config please tell me, but I posted it in different 
threads before and I also don't think the config is the problem here, 
since it sometimes works.

Regards,
Frank