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
