Download the PHP package zwilias/qman without Composer
On this page you can find all versions of the php package zwilias/qman. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package qman
QMan
An evented beanstalkd queue manager.
Core features
- Sane defaults, highly extensible and configurable
- Allows effortless reserving from a connection pool
- Supports graceful shutdown upon receiving a signal
- Protects job-execution from unexpected intrusions
- Extensible job-failure handling
- Built-in support for fine-grained PSR-3 logging
- Built-in support for queueing closures
Requirements
- PHP 5.5, PHP 5.6.
evdoes not support PHP 7 yet. - the pcntl extension.
ev, an interface to libev, the high performance full-featured event-loop.- one or more instances of beanstalkd.
Use case
QMan is optimized for multiple beanstalkd instances and a pool of workers listening to all of those.
Examples
Queueing a closure
Queueing a closure is quite possibly the easiest thing
Essentially, this is equivalent to the following:
Working the queue
Starting a worker with all the defaults injected, is easy:
The WorkerBuilder ensures the QMan\Worker is setup with all of its required dependencies and configuration.
Queueing custom commands
The ClosureCommand, while convenient, comes with two major downsides:
- Serializing closures is rather expensive, in terms of computational power required
- Unit-testing closures quickly devolves into a huge mess
As such, you'll quickly be writing custom commands on a regular basis.
A command should implement QMan\CommandInterface, which is easily done through extending QMan\AbstractCommand:
The getType() function should return a string which can be uniquely mapped to the class you want to execute. This
indirection is required in order to safely handle picking up stuff like renamed classes through a simple restart of the
worker.
In order for the QMan worker to pick up and execute your command, you'll need to make sure the instance of
CommandSerializerInterface will pick it up. QMan comes with a generic implementation of this interface, aptly named
GenericCommandSerializer. Let's make sure the class we created above is properly registered:
You could easily futureproof your application by gathering this type <-> class mapping, and representing the types as constants:
QMan's GenericCommandSerializer comes with a registerCommandTypes($map) function which can handle exactly the case
described above.
Configuration
Each Worker receives an instance of QManConfig. The following properties are currently included:
| Property | Default | Description |
|---|---|---|
maxMemoryUsage |
20MB | As soon as your memory usage goes over maxMemoryUsage, the worker is killed. |
maxTimeAlive |
24h | Your worker will be killed after maxTimeAlive passes. Workers are expected to be run in something like supervisord so they can be automatically restarted. |
terminationSignals |
[SIGTERM] |
Upon receiving this signal - while idle - the worker will gracefully shut down. If the signal is sent while a job is being processed, handling the signal will be postponed until the job is fully processed. |
maxTries |
3 | The maximal number of times a job can be executed resulting in failure before the job is buried. (1) |
defaultFailureDelay |
60s | Every time a job fails, it is released again, with a certain delay. The first time it is released, the delay will be defaultFailureDelay. The second time, it will be twice that, etc. (1) |
(1): Assuming you're using the default GenericJobFailureStrategy. Implementing a custom strategy for handling failed
jobs is, of course, perfectly possible.
Changing configuration is as simple as instantiating QManConfig, setting your configuration preferences and passing it
to the CommandBuilder:
Handling failed jobs
By default, qMan will employ a very simple strategy when handling failed jobs:
- a failed job will either be buried or released again
- if a job has failed less than
maxTriestimes in a row, it will be released with(tries in a row) * defaultFailureDelay - else, when it has failed
maxTriestimes in a row, it will be buried
Overriding this behavior can be done easily by implementing JobFailureStrategyInterface (which extends both PSR-3's
LoggerAwareInterface and qMan's ConfigAwareInterface.
Contributing
Pull requests are appreciated. Make sure code-quality (according to scrutinizer) doesn't suffer too badly and all code is thoroughly unit-tested.
Running the tests locally:
License
Copyright (c) 2015 Ilias Van Peer
Released under the MIT License, see the enclosed LICENSE file.
All versions of qman with dependencies
jeremeamia/superclosure Version ^2.1
psr/log Version ^1.0
php Version >=5.5.0
ext-ev Version ^0.2