Queue Bundle Laravel Package

Getting Started

Install via Composer and register the bundle in app/AppKernel.php:

composer require xaav/queue-bundle

$bundles = array(
    // ...
    new Xaav\QueueBundle\XaavQueueBundle(),
);

Look first at the bundle's Resources/config/services.xml (or .yml) — that's where the queue service and the worker command are wired. Next, open the worker console command class; it tells you how jobs are pulled, processed, and how the loop terminates. Finally, check the bundle's DependencyInjection/Configuration.php for whatever options (backends, sleep intervals, etc.) it exposes.

The canonical first use case is: define a job object as a Symfony service (or plain PHP class holding its data), push it onto the queue from a controller, and drain the queue with the bundle's worker command run from cron or a supervisor process:

app/console xaav:queue:worker   # exact name — check the Command class

Do a smoke test with a trivial "write a log line" job before wiring anything real. Since the bundle is old and thinly used, treat the source as the documentation.

Implementation Patterns

Job definition + worker dispatch. The bundle's model is a job class plus a worker that calls a known method (commonly run()/execute()) on it. Keep jobs small, idempotent, and free of request-scoped state. If the worker unserializes jobs, everything a job needs must be in its properties — injected services, not entities.

DI integration. Register job classes as services and let the dispatcher fetch them by id, or construct them inline and pass serializable payloads. If the bundle supports named queues, map one queue per concern (mail, image processing, exports) so a slow job type doesn't starve the fast one.

Daemon vs. cron. Two patterns work: (a) long-running worker via supervisor, or (b) short-lived workers fired from cron every minute. For anything touching Doctrine, prefer short-lived workers (see Gotchas). Either way, always run workers under a process manager — the bundle won't restart itself.

Service/controller integration. Wrap dispatch in your own thin service (JobDispatcher) rather than calling the queue service directly from controllers. That gives you one place to add logging, queue selection, and a dispatchAfterResponse-style optimization later.

If you're coming from Laravel: this is not Laravel's queue. There's no jobs table migration, no failed_jobs, no Horizon, no retry/backoff DSL, no ShouldQueue marker. Expect to hand-roll retries, failure recording, and monitoring. Budget for that up front.

Gotchas and Tips

• Symfony 2 only. The bundle targets Symfony2 and predates Symfony 3/4/5 Flex. Do not expect it to boot cleanly on modern Symfony — you'll likely be porting the service definitions at minimum. Verify the symfony/framework-bundle constraint in composer.json before committing.
• The README is thin; the source is the spec. With ~11 stars and zero dependents, treat every behavior as unverified. Read the worker command line-by-line before deploying: how it handles empty queues, whether it sleeps, and how it exits.
• No built-in retries/backoff (assume none until proven). Add your own wrapper: catch exceptions in the job, increment an attempt counter, and re-enqueue with a delay — or log to a dead-letter store. Without this, a single poison job can loop forever or vanish silently.
• Doctrine entity manager staleness. In a daemon worker, the EM goes stale and leaks memory. Call $em->clear() per job, or run short-lived workers. Same applies to any long-lived service you inject.
• Serialization surprises. If jobs are persisted (DB/Redis/file), closures, resources, and full entities won't survive. Store IDs and re-fetch inside the job.
• Idempotency is on you. No exactly-once guarantee exists here. Design every job to be safely re-runnable — guard side effects with a marker row or unique constraint.
• Debugging. Log at job start/end with a job identifier; without it you're grepping. Wrap the worker's run() in try/catch and log the exception plus payload before deciding whether to drop or requeue.
• Extension points. Override the job base class / interface and the worker command's processing method via a compiler pass or by copying the command into your app. That's usually faster than fighting the bundle's internals.
• Realistic recommendation. For a Laravel shop, this bundle offers little over illuminate/queue with the database or Redis driver, or Symfony's own Messenger with Doctrine/Redis transports. Use it only if you're maintaining a legacy Symfony2 app that already depends on it — otherwise pick a maintained queue and save yourself the retry/monitoring work.