On Tue, 15 Mar 2011 09:40:35 +0100 Jan Zelený <jzel...@redhat.com> wrote:
> Simo Sorce <sso...@redhat.com> wrote: > > Sorry Jan but it doesn't seem to do what I asked for. > > I'm not sure you are entirely right here. Let me explain: > > > As far as I can see you are overriding the last_usn when you > > connect, which is the exact opposite of what should be done. > > No, I'm not overriding it. I suppose you are referring to the first > patch (Add value of the last USN to server configuration). This is > indeed adding the value of last USN to sdap_server_opts during > connection, but this structure instance is only temporary and it is > stored internally after the connection creating process is finished > (see the second patch, the comparison of USN and server ID is in > there). > > > last_usn must never be set to whatever value is available from ldap. > > > > You only need to check if the value from ldap is lower then the > > currently internally value for last_usn if we are reconnecting to > > the same server,and you need to reset last_usn to 0 if the highest > > value reported from ldap is lower than the highest we internally > > stored. > > > > If we are connecting to a different server we always unconditionally > > reset last_usn to 0, as USNs are not global so checking values > > between different servers have no meaning. > > I'm not sure we should be resetting the value to 0. Even after fresh > replica installation the USN is not zero. In fact I didn't stumble > upon a single case of USN being zero (considering that it was > supported and used on the server). Can you please explain a little > bit more why we should do this and not just leave the USN which is > currently on the server? The last usn on the server is simply used to keep track of what is the highest usn used by the server. The one we use internally instead is the higher usn of any entry we actually *fetched* from the server. So while we remain attached to the same server, and this server is operating normally, the server's highest USN is always >= the one we have on file. If the server resets the USNs (this happen after a replica re-initialization in 389 DS for example), then we want to set the internal highest USN to 0 so that on the next enumeration search we will search for any entry with USN > 0. Using any other value may result in skipping entries that have changed between the time we fetched them and the replica was re-initialized. Same reasoning when we switch to a new server. Because USNs are not global, each server has it's own USN number space, so when we switch we have to reset to 0 as the highest USN we currently have on file has no meaning and using it in a search may make us skip to search entries that changed since our last fetch. In extreme cases, if the new server have USNs that are much lower then the ones in the previous server (because it was just re-initialized for example), then we would fail to get any new change for potentially a very long period of time, at least until something forces us to do a full rescan, and yet because we do not reset the highest usn on a full rescan we may still keep not getting changes after the full rescan. So, setting the usn to 0 on a new connection (or a re-initialized server) is fundamental, and setting it to the current reported highest usn from the server is completely wrong and defeats the purpose. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
