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
>>
>
>
