Hi Tim, Currently, unfortunately, only the inverse is configurable.
Due to an edge-case in job distribution (job is started and executed on CRX master, master crashes before slave is updated, slave becomes master, slave executes job a second time) the suggestion is to make anything *but* the CRX master become the discovery leader. So this was an explicit goal of the current implementation. To achieve this, a repository descriptor is configurable (leaderElectionRepositoryDescriptor) which, when set, can enforce exactly this: that the crx-master is not the leader if there is any slave around. I fear there is no explicit way atm to force the behavior you want. About the closest one I can think of is: the leader is defined to be stable, ie once an instance is leader, it stays leader until it leaves/crashes. Or in other words: the first instance started on a fresh setup becomes leader. But that might not suffice in your case I assume.. Cheers, Stefan On 3/16/15 12:15 PM, "Timothée Maret" <[email protected]> wrote: >Hi, > >In a deployment, we use a CRX (TarPM) active/passive cluster composed of >one master instance and one slave instance. >We run background jobs on this deployment and we want to have them run on >the CRX master only in order to guarantee no writes on the slave thus >keeping the activate/passive scheme. > >The way we currently do it is by checking in our background code, that the >instance is the Sling leader and only run the code if the instance is the >leader. > >This works only if the following holds at any time > >Sling leader == CRX master > >We experienced some cases where this seemed not to be the case. >Should we expect the above mentioned mapping to be valid or should be find >another way to enforce background services to only execute on the master ? >We could use some CRX specific code for that, but our code would not >become >portable to other MK. > >Regards, > >Timothee
