Queuing Laravel Package

Getting Started

Read the provider before you install anything. There is no usage documentation for this package — no README with examples in the release notes (v1.0.3 is "CS fixes, MIT license"), and the repo sits under GrahamDeprecated. The entire integration surface is one service provider and one composer.json. Open those first:

• composer.json — tells you the real support matrix. Expect illuminate/queue / illuminate/support at 4.2.* and a PHP 5.x platform constraint. If your app is on anything newer, stop here; Composer will hard-conflict and no amount of --ignore-platform-reqs makes that safe.
• src/GrahamCampbell/Queuing/QueuingServiceProvider.php — the whole package. It registers container bindings and overrides the queue manager to shave per-job worker overhead. Read it end-to-end; it is short, and it is the only specification you will get.

Minimal install (Laravel 4.2 only). There is no package auto-discovery in 4.2, so wiring is manual:

// app/config/app.php
'providers' => array(
    // ...
    'Illuminate\Queue\QueueServiceProvider',
    'GrahamCampbell\Queuing\QueuingServiceProvider', // must come AFTER
),

Pin a commit hash rather than a version constraint — the tags are not a reliable release process. Then confirm the swap actually took effect:

php artisan tinker
> get_class(app('queue'));   // should differ from stock Illuminate\Queue\QueueManager

Your first use case should be a measurement, not a feature. The value proposition is the unsubstantiated phrase "queuing performance increases." Before trusting it, run one representative job class through queue:work on stock 4.2, record wall-clock time and jobs/minute, then repeat with the provider enabled against identical payloads. If you cannot demonstrate the delta on your own workload, you have your answer and you can uninstall without further investigation.

Implementation Patterns

Baseline-then-swap, per queue. Keep the stock path runnable so you can revert in one config change. The cleanest shape is a flag in app/config/queue.php that conditionally registers the provider, so staging can A/B the same codebase against the same driver:

if (Config::get('queue.performance_provider')) {
    $app->register('GrahamCampbell\Queuing\QueuingServiceProvider');
}

Keep jobs boring and serializable. Because the package touches worker internals, the safest posture is job classes that carry only scalars and IDs in their constructors and re-fetch models inside fire(). This insulates you from any change in how the driver serializes payloads and keeps the jobs portable back to the stock driver if you rip the package out.

Route work through named queues and per-queue workers. Queue::pushOn('mail', new SendReceipt($id)) with a dedicated queue:work --queue=mail gives you an isolation boundary: if the override misbehaves under load, it degrades one lane, not the whole fleet. It also gives you per-lane counters, which is the closest thing to observability you will get on 4.2.

Assert on dispatch, not on the driver. In tests, mock the queue facade and assert the job/payload/queue name. Anything that asserts driver behaviour is asserting the thing this package silently replaces, and will pass in CI and fail in production.

Queue::shouldReceive('pushOn')->once()->with('mail', Mockery::type('SendReceipt'));

Document the extension points you rely on as forbidden. If you subclass the provider or override a binding, add a comment naming the exact stock class it shadows. That comment is the removal ticket when the migration lands.

Gotchas and Tips

Forgetting the providers array is the #1 failure. Nothing errors, nothing warns, jobs just run at stock speed and you conclude the package "doesn't help." Always verify with the get_class(app('queue')) check above before benchmarking.

Provider ordering matters. Registering before Illuminate\Queue\QueueServiceProvider means the framework's binding wins and your override is dead. Registering twice (once conditionally, once in app.php) produces duplicate worker hooks — subtle, intermittent, and only visible under concurrency.

The changelog contradicts the marketing copy. The description claims current Laravel/PHP support, auto-discovered providers, and being "fully tested and documented." The changelog, namespace, and GrahamDeprecated org say otherwise. When the docs and the code disagree, the code is the truth — and here the code says 2014.

Silent job loss is the failure mode to instrument for first. A throughput-tuned driver can trade durability or acknowledgment for speed, and the symptom is jobs that never run and never appear in failed_jobs. Log a dispatch record and a completion record with a shared ID, and reconcile counts nightly. Do not rely on failure counts alone to tell you the queue is healthy.

Watch for lost retry/backoff semantics. If the override bypasses Laravel's release-and-retry contract, --tries and --sleep may appear to work while jobs quietly disappear after one attempt. Test a deliberately failing job end-to-end and confirm it lands in failed_jobs with the expected attempt count before you go anywhere near production traffic.

There is no observability to fall back on. 4.2 predates Horizon and queue:monitor. Whatever throughput you gain, you lose the ability to see queue depth, job age, or worker saturation. If your actual problem is "we don't know why jobs are slow," this package is the wrong category of fix and no amount of profiling it will help.

You own this code from day one. No upstream triage, no security channel, no dependents to consult. Write the on-call runbook from source, name an owner, and set a dated removal tied to your framework migration — because a queue driver is exactly where 3 a.m. guesswork costs the most.