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
