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

Re: syncrepl simplification

Kurt D. Zeilenga wrote:

At 09:19 PM 1/12/2005, Howard Chu wrote:

Kurt D. Zeilenga wrote:

The rationale, I believe, for multiple consumer contexts
within a database context was that administrators could state
different consumer policies for different areas of the DIT.

I'll have to think about that some more.

I've been, too. In particular, I think the above rationale more
applies to provider contexts, where one might want to have different
server handling of different requests. For instance, one might
want to have one area covered by a session log and one area not.

That actually makes sense, although the current code doesn't allow for this. It would require the sessionlog config directive to take a search specifier (baseDN of a subtree at least) to differentiate logs. Again this is problematic when you're dealing with ModDN requests; if an entry moves across a sessionlog boundary then one or both logs becomes useless.

At the moment all updates in a context are recorded in all the active sessionlogs, so the only difference between the multiple logs is their size. This also seems unnecessary, it would be best to have a single log of the largest practical size. I have a feeling this sessionlog stuff was not thoroughly thought out; the fact that there is no config keyword for the sid on the consumer implies to me that it was never even tested before.

Given all of this, I think it would be best to have only one sessionlog per provider, and we can forget about the sid parameter entirely.

On the consumer side, we just just require additional
database contexts where the admin desires different consumer

To me, it still sounds like a recipe for disaster. If the separate consumer contexts are talking to different providers, then you have the cascade problem I mentioned before. If the contexts are all pulling from the same provider, then I guess it works. I still don't see any rationale for the updatedn on the consumer; surely any data that the provider returns must satisfy the consumer criteria and therefore must be reflected into the consumer DB.

I concur with regards to the updatedn. Also, we need to revisit
consumer ACLs. Seems odd to me that syncrepl consumer needs
permission to write into its own database.

Yes. OK, I'm going to delete the updatedn stuff then.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support