Hi, On 18 April 2016 at 15:20, Timothée Maret <[email protected]> wrote:
> Hi, > > > > Is there a reason that you think the implementation under SLING-5646 > won't > > support the batch use case ? > > > > > > > One aspect that may differentiate asset processing from general job use > case is the guarantees offered from the job delivery. Some use case would > be fine with "at-least-one" or "maybe" delivery whereas some use case will > need "exactly-one" delivery. > > Ideally, each use case could select the level of guarantee it needs > depending on the use case. > > @Ian the MoM API at SLING-5646 and its existing activemq impl at does not > seems to define clearly the delivery. Does that mean the jobs are meant to > be delivered with "maybe" guarantees (and have the application layer handle > the ack+re-send) ? > The MoM API leaves that aspect to configuration of the MoM provider on a Queue by Queue basis. For the Queue's used by the SLING-5646, Jobs API the style of delivery is still abstract. If you wanted to submit a Job that was guaranteed to be processed once and once only, then you would send it to a queue configured to deliver once and once only. If you wanted to submit a job with "maybee" or "at-least-once" semantics, then you would configure the queue appropriately. There is nothing in the SLING-5646 Jobs implementation that dictates which style of queue has to be used, although there is an expectation that for standard Jobs processing a once and once only queue would be used. The MoM API could be used by things other than Jobs which is why it became an API in the PoC. The default implementation of the MoM API in the PoC is based on ActiveMQ. IIUC it is possible to configure queues via configuration, although I have not verified that. It it is not, some code in the PoC MoM API impl bundle might need to lookup what type of queue is required, and select a different code path. Best Regards Ian > > Regards, > > Timothee >
