Howard Chu wrote:
In at least one case I'm seeing a valid
update being rejected because the incoming cookie seems to have been confused
with another one. This happens when a NEW_COOKIE message is received. I'll
note that sending NEW_COOKIE messages is a recent change (ITS#5972), and there
is no valid case for them to be occurring in test050. I.e., NEW_COOKIE should
be sent in a partial replication situation, where an entry changed in the
naming context but it's not within the consumer's scope of interest. In
test050, the consumer's scope of interest is the entire naming context. So
this at least gives me one area to look for a fix.
This piece of the ITS#5972 patch is part of the problem
--- syncprov.c 5 Mar 2009 16:53:01 -0000 1.266
+++ syncprov.c 12 Mar 2009 08:42:54 -0000
@@ -1245,7 +1245,7 @@
} else if ( !saveit&& found ) {
/* send DELETE */
syncprov_qresp( opc, ss, LDAP_SYNC_DELETE );
- } else if ( !saveit ) {
+ } else if ( !saveit&& !fc.fscope ) {
syncprov_qresp( opc, ss, LDAP_SYNC_NEW_COOKIE );
}
if ( !saveit&& found ) {
My diff above is also not the correct fix, which is why I haven't committed it
yet.
The current operation may not have been caught by the previous if conditions
for 3 reasons:
1) the change is out of the consumer's scope
2) the change doesn't match the consumer's filter
3) the change is older than the consumer's cookie
The NEW_COOKIE message must only be sent for conditions 1 and 2, but it's
currently also being sent for 3. Since the cookie comparison is tacked onto
the consumer's filter, an additional comparison is needed to weed this out.
(Normally 3 can't be true, but this is MMR where the consumer might have
already received this change from some other provider.)
I haven't looked yet, but I suspect there is a corresponding bug in the
consumer where it acts on a NEW_COOKIE message whether it's valid or not.