Stelios Grigoriadis wrote:
On Fri, 2007-09-28 at 17:02 -0700, Howard Chu wrote:
Stelios Grigoriadis wrote:
But, the problem remains and I have no idea why this happens. I somehow still suspect that the problem still is in the initial phase of the sync operation (refresh stage). It might be that, some of the not-yet committed modifications don't make it into the result set in the search operation. Later after another entry is added, the "lost" entries are never to be synced over.
This also cannot be the cause. The contextCSN is snapshotted at the beginning of a refresh. Only updates between the consumer's cookie CSN and the snapshot CSN are sent to the consumer. Any entries added during this refresh will be excluded from the update, and the consumer will then record the snapshot CSN. Any entries the consumer didn't pick up in this refresh pass will be picked up in the next refresh.
I agree with you, I just didn't see the "next refresh" in the code. I thought it refreshed only once and then the master would write back all subsequent changes (syncprov_op_response -> syncprov_qstart etc.)
True, I was speaking of a refreshOnly case. Since you're apparently talking about refreshAndPersist, I guess the situation is different.
Looking at syncprov_search_response() around line 1868 I guess it's possible that a new entry was added (entryCSN > snapshotCSN) before the persistent search was queued up (which is at line 1991). If the Add was in progress but there were no persistent searches known at that time, then the resulting entry will not be propagated during the Persist phase. So it seems that we should make an exception in the test at 1868 and allow the entry to be sent if the current consumer is a refreshAndPersist consumer. Checking your debug logs (which I asked about in my previous message) would confirm that this is indeed the problem, and would also verify the solution.