Hi all,
as you probably know there are these weird JobQueue packages floating around (previously TYPO3.Jobqueue.*
now Flowpack.JobQueue.*
).
But there is no documentation whatsoever and the code can use some cleanup/tweaking.
That’s what I started doing (with support by the great folks from t3n.de). And it turned out to be more than just a little tweaking so I’d like to get your opinion before pushing a lot of Pull-Requests.
So here’s what I did so far:
New Features
- Documentation
- Improved error handling: Failed Jobs will be re-released for a configurable amount of trials before they are “aborted”
- Simple
SerialQueue
implementation that allows to execute jobs via sub request, so it won’t require any 3rd party tool nor server loop (i.e. as “poor mans solution” for async tasks in Neos) - New
Flowpack.JobQueue.Doctrine
package that allows db-based queues (SqlLite, MySql, … defaults to the current db) - Implementation specific options for the “Defer” annotation (e.g.
@Job\Defer(queueName="some-queue", options="{delay: 123}")
) - Signals for most events allowing 3rd party packages to hook into the processing of jobs/messages
(Breaking) Changes
The public API of JobManager
, CLI and Defer annotation have been adjusted in a backwards compatible manner, but there are some changes that might break depending code:
The QueueInterface
has been changed, including one important behavioral modification:
The signature of submit(Message $message, array $options = [])
has been changed to submit($payload, array $options = [])
.
Previously a message with the same id of a previous message were discarded. This is no longer possible. The reason is that the behavior was not reliable (depending on the implementation the id was free again as soon as the message was reserved/processed) and is not supported by many queue implementations (for good reasons).
Now I wonder: Did anyone rely on that feature of a message id preventing the message from being published twice?
In any case I’d suggest to push the major changes to a new branch 1.x so that the existing implementations can still be maintained if required.