On 13 April 2016 at 07:58, Chetan Mehrotra <[email protected]> wrote:
> The requirement here I think is similar to how a Servlet is registered > with HttpService via the whiteboard pattern. So in Job case a > JobConsumer can be registered with a Filter which list the job > attributes it can process. Then JobSubSystem would work on the > whiteboard pattern and registers the JobConsumer with the matching > queue based on the filter. > Agreed, JobConsumer uses a OSGi Whiteboard pattern. QueueConsumer is a configuration factory. The underlying class for QueueConsumer doesn't use a whiteboard pattern because the MoM API was originally written with the concept of a QueueSession. I guess it could if it was important to avoid a listener pattern, drop the QueueSession and switch to a whiteboard pattern. At present the only thing a QueueSession is used for is to dispose of itself. > > > Message Queue -> QueueConsumer -> JobSubSystem -> JobConsumer > > Not sure about the distinction between QueueConsumer and JobSubSystem. > May be you are distinguishing between a whiteboard impl which listens > for queue ( QueueConsumer) and another whiteboard impl which listens > for JobConsumer (JobSubSystem). > I have implemented the above in the branch pushed a moment ago. Having done that I think it's better than without the QueueConsumer because it provides a level of indirection via OSGi Configuration. The ability for an instance to process message Queue can be controlled by the configuration of the QueueConsumers [1] present on an instance. While the availability of JobConsumers controls which types of jobs can be processed on that instance. That decouples the JobConsumer from the queue it consumes, leaving the queue and its nature entirely to configuration. Best Regards Ian 1 https://github.com/ieb/sling/blob/jobs_28/contrib/extensions/jobs/core/src/main/java/org/apache/sling/jobs/impl/JobQueueConsumerFactory.java > Chetan Mehrotra > > > On Tue, Apr 12, 2016 at 2:10 PM, Ian Boston <[email protected]> wrote: > > Hi, > > Under [1] I am working on a PoC to implement a distributed Jobs sub > system > > that works using message passing as the underlying concept. The PoC uses > > JMS provided by ActiveMQ. I have a question that I have not answered in > the > > implementation and would like to discuss. > > > > A tiny bit of background: Jobs are queued by sending messages to a Queue. > > The messages are dequeued and the Jobs are executed. There is an API [2], > > JobConsumer, that Jobs would implement. For more background have a look > at > > the README.md files in the branch referenced by [1][2]. > > > > I am wondering the best way to connect the Queue to the JobConsumer, > hence > > this email. > > > > Currently, I am thinking a component uses OSGi DS to maintain a list of > > active JobConsumer implementations. That component registers the > > JobConsumers with the Queue implementation and calls JobConsumer.execute > as > > messages are dequeued. Its the registration part that worries me. > > > > A JobConsumer has an OSGi property listing the queues it wants to be > > registered against. I am worried that that doesn't provide sufficient > > decoupling between what the JobConsumer does, and how it gets its > messages. > > Queues should, I think, be flexible and not bound to the Job being > > executed, but be able to be configured to suit a deployment. > > > > Perhaps rather than: > > Message Queue[3] -> JobSubSystem -> JobConsumer > > where the JobConsumer directly subscribes to a named queue. > > > > it should be: > > > > Message Queue -> QueueConsumer -> JobSubSystem -> JobConsumer > > Where the JobConsumer advertises a type of job it can execute. > > The JobSubsystem maintains a registry of JobConsumers to which it > > dispatches on type of job. > > The deployment configures 1 - n QueueConsumers with varying configuration > > which consume messages from named queues. > > > > On the other hand, having configurable QueueConsumers might be overkill > and > > something that a implementation of [3] could handle internally via > > configuration (ActiveMQ probably can). > > > > Even if QueueConsumers did almost nothing, I am leaning towards that > > additional layer of indirection. > > > > wdyt? > > > > Best Regards > > Ian > > > > > > 1 https://issues.apache.org/jira/browse/SLING-5646 > > 2 > > > https://github.com/ieb/sling/blob/jobs_28/contrib/extensions/jobs/core/src/main/java/org/apache/sling/jobs/JobConsumer.java > > 3 > > > https://github.com/ieb/sling/blob/jobs_28/contrib/extensions/jobs/mom-api/src/main/java/org/apache/sling/mom/QueueManager.java >
