In general yes, but not for the Job Consumer Manager - the configuration has a special property set which excludes it from writing back to the repository and therefore distributing it
Carsten 2013/9/6 Ian Boston <[email protected]> > If the config is stored in the repository, wont that propagate from > master to slave and visa versa ? > The JavaDocs on Configuration.update(Dictionary) say changes are stored. > > On 6 September 2013 13:40, Carsten Ziegeler <[email protected]> wrote: > > Hmm, I would rather get the configuration dictionary from the config > admin > > and update that > > > > Carsten > > > > > > 2013/9/6 Ian Boston <[email protected]> > > > >> I meant serviceRegistration not serviceReference, but I cant get it > >> seems like its not possible to get hold of a serviceRegistration from > >> another bundle. > >> > >> On 6 September 2013 13:31, Ian Boston <[email protected]> wrote: > >> > Hi, > >> > Just to be clear you are saying programatically manipulate the OSGi > >> > configuration of the JobConsumerManager when an instance initialises > >> > or transitions from master<->slave ? > >> > > >> > eg > >> > > >> > on a topology change > >> > get a serviceReference to the JobConsumerManager > >> > using serviceReference.setProperties(Dictionary) > >> > set a blacklist appropriate to the master/slave status > >> > of the instance. > >> > > >> > > >> > I am assuming I don't need to worry about the other OSGi properties, > >> > however the JavaDoc on setProperties is not explicit on what happens > >> > to properties that are not set ? > >> > > >> > I am also assuming this wont interact badly with any stored > >> > configuration state ? > >> > > >> > Best Regards > >> > Ian > >> > > >> > On 6 September 2013 12:35, Ian Boston <[email protected]> wrote: > >> >> Cool, thanks, > >> >> I'll go down the route you suggest. > >> >> Ian > >> >> > >> >> On 6 September 2013 11:45, Carsten Ziegeler <[email protected]> > >> wrote: > >> >>> Hi Ian, > >> >>> > >> >>> no, you don't implement a PropertyProvider for this - this is done > by > >> the > >> >>> job implementation for you (JobConsumerManager). > >> >>> The JobConsumerManager collects all active JobConsumer queries their > >> >>> supported topics and provides this information through the topology > by > >> >>> registering the PropertyProvider. > >> >>> Basically, you have three choices: either you disable the job > consumer > >> on > >> >>> an instance, you change the topics registration property of that > >> service or > >> >>> the consumer manager allows to configure whitelist and blacklist > >> topics. > >> >>> Which in most cases is the easiest solution. > >> >>> A topology change causes the job handling to restart, if you do a > >> consumer > >> >>> change based on that, this results in a new topology event and the > job > >> >>> handler will restart again. At least that's how it is implemented > right > >> >>> now, as this is the easiest way of implementing it. However, the > >> restart > >> >>> comes with a delay, so if the additional events happen within this > >> delay, > >> >>> you end up with exactly one restart (this is why we have the delay). > >> >>> > >> >>> Regards > >> >>> Carsten > >> >>> > >> >>> > >> >>> 2013/9/6 Ian Boston <[email protected]> > >> >>> > >> >>>> Hi, > >> >>>> (Probably a question for Carsten). > >> >>>> > >> >>>> Is the right way to implement topology based queue exclusion by > >> >>>> implementing a topology discovery PropertyProvider that provides > the > >> >>>> property: > >> >>>> > >> >>>> org.apache.sling.event.jobs.consumer.topics > >> >>>> > >> >>>> containing a , separated list of topics the instance can handle. > >> >>>> > >> >>>> If so I have 2 questions: > >> >>>> > >> >>>> Since this list is topology dependent (depends on which is master) > and > >> >>>> will itself have to be generated after a topology change which may > >> >>>> take some time to filter through the discovery hub spoke > >> >>>> implementation, will it cause the Job Queue to restart multiple > times > >> >>>> on a relevant property change. ? > >> >>>> > >> >>>> Also, how are Topics excluded from a list of capabilities for each > >> >>>> instance. I have read through the code in the constructor of > >> >>>> TopologyCapabilities and the getPotentialTargets, detectTartgets > and I > >> >>>> cant see how to exclude a topic from an instance, only how to > include. > >> >>>> What is the best way of excluding a topic from a instance without > >> >>>> having to whitelist all known topics. ? > >> >>>> > >> >>>> Best Regards > >> >>>> Ian > >> >>>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Carsten Ziegeler > >> >>> [email protected] > >> > > > > > > > > -- > > Carsten Ziegeler > > [email protected] > -- Carsten Ziegeler [email protected]
