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
