PHPackages                             released/queues-and-jobs - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Queues & Workers](/categories/queues)
4. /
5. released/queues-and-jobs

ActiveSymfony-bundle[Queues & Workers](/categories/queues)

released/queues-and-jobs
========================

11.2k1PHP

Since Mar 18Pushed 7y ago1 watchersCompare

[ Source](https://github.com/ryabenko-pro/released-queues-and-jobs)[ Packagist](https://packagist.org/packages/released/queues-and-jobs)[ RSS](/packages/released-queues-and-jobs/feed)WikiDiscussions master Synced yesterday

READMEChangelogDependenciesVersions (2)Used By (0)

Queues and Jobs
===============

[](#queues-and-jobs)

> **This is not a message queue!**

Queues and Jobs is a framework for building scalable applications. Scalability is achieved thru moving heavy and risky operations to be executed asynchronously in separate thread.

Queues
======

[](#queues)

Queues adds simple move-to-background functionality which may be useful in many cases. In modern world most of operations can be asynchronous and what can be asynchronous **must be asynchronous**.

### Case 1: Shopping Cart

[](#case-1-shopping-cart)

When user clicks on checkout cart this does not mean order must be placed exact same second. Instead we can mark cart as processing and plan a task to make checkout in background. User will usually not notice a difference between synchronous and asynchronous checkout, but if something will go wrong during checkout process in synchronous process user will see error and a customer may be lost, while in asynchronous manner failed operation may be replayed and only result in delay in order processing. This is also bad but not as critical as left card.

### Case 2: Business flow

[](#case-2-business-flow)

When you have complex business flow that depends on external services you might get whole process failed because of a single failed step. To solve this you might split your flow to independent steps and execute each of them sequentially or in parallel.

For example lets take a card checkout when for each item you need place a quote, validate order on partner service and if everything ok place an order and notify partner service about this order.

If you do all operations in the same thread each step can break system due to temporary issue on 3rd party API and you must be ready to restart a process (by loosing previous quote) or catch it where it break.

Instead you can plan a task for each to be executed sequentially. When any step fails you simply restart it (if not done automatically) and flow goes like nothing happens.

Configuration
-------------

[](#configuration)

```
released_queue:
    transport: db # db / amqp / inline
    template: ::base.html.twig  # optional
    doctrine.orm.default_entity_manager: default # optional
    server_id: (Optional unique server identifier - must be set if a task with `local` exist)
    types:
        echo: # Must be same as `getType` return value
            name: Example echo task
            class_name: Released\QueueBundle\Model\EchoTask
            local: false # Force this type of tasks run only on the server it was created on
```

> If you are getting `Type 'your_task' not found` exception most likely you forgot to define task in `config.yml`.

Local tasks will only be run on the server they were created. This is useful for cases like processing uploaded file in background with more then one server.

Usage
-----

[](#usage)

Usage is very simple. To create a queueable task you need just to extend class from `BaseTask` and implement abstract methods. After you do that you can plan a task using `released.queue.task_queue.service` service:

```