Re: ITS#8102, syncrepl concurrency

[Andrew Findlay <andrew.findlay@skills-1st.co.uk>]

On Tue, May 12, 2015 at 07:27:22PM +0100, Howard Chu wrote:

> Or, each session should be established completely sequentially - do
> a complete refresh from provider #1, then do the same for provider
> #2, etc... In a quiescent setup, the refreshes after provider #1
> will be no-ops because the consumer is already up to date. In a busy
> setup, each refresh will still have work to do but it will be a
> smaller volume after provider #1's refresh completes.

Presumably the earlier connections would have entered persist state by
then, so some of the changes could already have arrived.

> Simplest would be to just establish the first connection and ignore
> other providers unless the first connection breaks. Unfortunately
> this wouldn't be reliable in MMR - you could have two nodes pointed
> at each other, ignoring any other nodes in the configuration.

That suggests that the consumer should attempt refresh from every supplier
whenever it can establish a new connection, but that a preference order
should be applied so that it does not try to refresh from a distant/slow
provider first.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------