Re: Sling JMS Based Job Support - Difference between queue name and job type

[Chetan Mehrotra]

Thanks Ian for the details. That helps!
Chetan Mehrotra


On Wed, Sep 21, 2016 at 4:32 PM, Ian Boston  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  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 
>> 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
>>>
>>
>>

Re: Sling JMS Based Job Support - Difference between queue name and job type

[Ian Boston]

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

Re: Sling JMS Based Job Support - Difference between queue name and job type

[Ian Boston]

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

Sling JMS Based Job Support - Difference between queue name and job type

[Chetan Mehrotra]

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