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]
