| commit | d89cda1cb5093a614620fbcb7614f891e40233a5 | [log] [tgz] |
|---|---|---|
| author | Ian Boston <ieb@apache.org> | Wed Jul 27 12:10:12 2016 +0000 |
| committer | Ian Boston <ieb@apache.org> | Wed Jul 27 12:10:12 2016 +0000 |
| tree | 9d190b551e092cfcffa3344d3eb3eb134362363f |
SLING-5646 MoM API and JMS implementation with example usage by Jobs implementation. Squashes 27 commits from https://github.com/ieb/sling/tree/jobs_28 as follows. Added first stab at a message oriented job subsystem Added basic implementation for the manager keeping queue implementation details abstracted Added ActiveMQ implementation for queues and topics, and fixed a number of the the SPI interfaces in the process Basic Test coverate for OOT JMS Broker Extracted a MOM API with no Jobs or JMS references, test coverage for ActiveMQ impl is 100% class, 93% method, 75% line Added missing license headers, documentation and cleaned out unused interfaces Fixed JMS Transaction issue found by @tmaret Coverage for the majority of the jobs code is complete Basic unit test coverage complete, core has 94% by lines, AMQ 74%, 100% classes and methods Added testing environment for a runnign server, Not working yet Added ability for detect when the OSGi container has completed bundle startup without having to perform http requests Start at IT testing with Crankstart Fixed issues with shutdown inside a Crankstart container Working Crankstart IT framework Version that uses Q->Jobs->JobConsumer pattern Added a Queue Factory to allow configuration of multiple queues between the MOM API and Job Subsystem and move JobConsumers to register with a Job type Migrated Subscribers and QueueReaders to a OSGi whiteboard pattern after discussion on Sling Dev Changes the JobConsumer to use a Callback rather than return a job. This was suggested offlist by others in Adobe as a way of improving resource consumption Added Types to improve type safety in certain areas after suggestions offlist Fixed issue with OSGi startup in IntelliJ caused by version 4 of the Felix framework bundle being present inside the maven pom. Strangely a command line build was not impacted. Added integration test bundle to test service. Adjusted some of the APIs to make using the Job Sub System easier Integration tests now starting jobs from messages Fixed Startup to work in real Sling/AEM container. The Active MQ OSGi bundle contains additional dependencies that cause all sorts of problems, AMQ is now being embedded into the AMQ MOM Impl bundle. Fixed Queue expriy bug and added AEM Fiddle to run jobs Added Documentation for configuration and default sample configuration Added Explicit requeue mechanims rather than relying on AMQ's requeue capabilities Moved MoM to new Home git-svn-id: https://svn.apache.org/repos/asf/sling/trunk@1754255 13f79535-47bb-0310-9956-ffa450edef68
This bundle contains an API to support 2 types of message passing. Pub/Sub and Queue. Pub/Sub message passing supports the publication of messages to multiple subscribers. Queue support guaranteed delivery of a message to one and only one receiver. Pub/Sub messages are organised by a Topic name. Queues are named. There are no implementation details in this bundle and no bindings to any one MoM implementation, although it is expected that this API could be implemented over either JMS or a AMQP client.
Messages that are sent to a topic by publishing are received by all subscribers that were active at the time the message is published.
To publish a message use the TopicManager API
topicManager.publish(String topic, Map<String, Object> message);
where:
topic is the name of the topic to which the message is published
message is the message as a Map or Maps.
To subscribe to a topic the caller must also use the TopicManager API
Subscription subscription = subscribe(Subscriber subscriber, String[] topicNames,MessageFilter filter);
where:
subscription is a Subsctipion objects which must be disposed (call dispose()) when the subscription ends.
topicNames is an array of topic names.
messageFilter is a MessageFilter implementation that accepts only those messages the subscriber is interested in.
The API does not impose any stcuture on topic names, but the underlying implementation might.
A Queue implementation guarantees that messages will be delivered to one and only once QueueReader in the order in which the messages were added to the Queue. The QueueReader implementation may request to re-queue messages. The implementation should retry requeued messages after a suitable delay.
To add a message to a named queue use the QueueManager API
queueManager.add(String name, Map<String, Object> message);
where:
name is the name of the queue.
message is the message in map of maps form.
To recieve messages from the queue ise the QueueManager API
QueueSession queueSession = queueManager.open( QueueReader queueReader, String name, MessageFilter messageFilter);
where:
queueSession is a QueueSession instance that must be closed (call close()) when the the queue reader requires no
more messages,
queueReader is a QueueReader implemetnation that will get delivered messages from the queue.
name is the name of the queueu.
messageFilter is a message filter intended to accept messages.
The QueueManager implementation will deliver messages to the queueReader.onMessage(...) method. The implementation of the QueueReader.onMessage method may process the message, returning normally, or request the message is requeued by throwing a RequeueMessageExption.