Sorry, not slightly correct - if you create the configuration for the first time, make sure to set the property "org.apache.sling.installer.configuration.persist" to the value "false"
Carsten 2013/9/6 Carsten Ziegeler <cziege...@apache.org> > 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 <i...@tfd.co.uk> > >> 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 <cziege...@apache.org> wrote: >> > Hmm, I would rather get the configuration dictionary from the config >> admin >> > and update that >> > >> > Carsten >> > >> > >> > 2013/9/6 Ian Boston <i...@tfd.co.uk> >> > >> >> 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 <i...@tfd.co.uk> 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 <i...@tfd.co.uk> wrote: >> >> >> Cool, thanks, >> >> >> I'll go down the route you suggest. >> >> >> Ian >> >> >> >> >> >> On 6 September 2013 11:45, Carsten Ziegeler <cziege...@apache.org> >> >> 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 <i...@tfd.co.uk> >> >> >>> >> >> >>>> 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 >> >> >>> cziege...@apache.org >> >> >> > >> > >> > >> > -- >> > Carsten Ziegeler >> > cziege...@apache.org >> > > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
