Thanks Ian for the details. That helps!
Chetan Mehrotra
On Wed, Sep 21, 2016 at 4:32 PM, Ian Boston <i...@tfd.co.uk> wrote:
> Hi,
> Documentation (README.md) and JavaDoc has been updated. Hopefully that will
> make it easier for everyone to follow, including myself in a few months
> time.
> Best Regards
> Ian
>
> On 21 September 2016 at 11:08, Ian Boston <i...@tfd.co.uk> wrote:
>
>> Hi,
>> Its been a while since I have looked at this code, and I realise the
>> JavaDoc on the API isn't quite as complete as it should be. The bundle was
>> originally intended as an example of how to use the MoM API, but it does
>> serve as a Job subsystem.
>>
>> Its probably best to talk about how a job is run first.
>> A message goes onto a named queue that that the JobQueueConsumer consumes.
>> That message updates the state of a job and takes it through its
>> lifecycle. There may be many messages on the queue relating to each Job.
>> (eg abort).
>> The JobQueueConsumer will forward all messages it recognises as Job
>> related to the JobSubsystem.
>> The JobSubsystem will have multiple JobConsumers registered with it, each
>> registration capable of executing a number of JobTypes.
>> If a sequence of messages is dequeued to start a Job, the appropriate
>> JobConsumer capable of executing that Job will execute that Job.
>>
>> Hierarchically the execution of jobs follows
>>
>> Queue -> JobQueueConsumer -> JobSubsystem -> JobConsumer
>>
>> To consume a job of a certain type on a certain queue, implement the
>> JobConsumer API and give it a list of JobTypes that it can execute. Load
>> that into an OSGi container with a JobQueueConsumer configured to consume a
>> named queue.
>>
>> To queue jobs, do as you have done with the JobBuilder.
>>
>> The indirections are there to allow multiple queues to exist in the system
>> each capable of routing messages to multiple job consumers, potentially via
>> multiple routes.
>>
>> The Jobs API was an example of how to use the MoM API. I will try and
>> improve the documentation to capture the above.
>>
>> HTH
>> Best Regards
>> Ian
>>
>>
>> On 21 September 2016 at 07:48, Chetan Mehrotra <chetan.mehro...@gmail.com>
>> wrote:
>>
>>> I was looking at the Sling JMS based Job SLING-5645 and trying to
>>> understand the api flow.
>>>
>>> Sender side submits a job for a given queue and job type
>>>
>>> ------
>>> Job job = jobManager.newJobBuilder(Types.jobQueue(TOPIC),
>>> Types.jobType(AsyncJobConsumer.JOB_TYPE)).addProperties(
>>> ImmutableMap.of("jobtest", (Object) "jobtest")).add();
>>> ------
>>>
>>> While on consumer side we specify only job type
>>>
>>> -------
>>> @Component(immediate = true)
>>> @Properties({
>>> @Property(name = JobConsumer.JOB_TYPES, cardinality =
>>> Integer.MAX_VALUE, value = {
>>> AsyncJobConsumer.JOB_TYPE
>>> })
>>> })
>>> @Service(value = JobConsumer.class)
>>> public class AsyncJobConsumer implements JobConsumer
>>> -------
>>>
>>> So whats the purpose of queue name here?
>>>
>>> Chetan Mehrotra
>>>
>>
>>
