Rabbitmq Bundle Laravel Package

Getting Started

This is a Symfony2 bundle, not a Laravel package — the first and most important thing to internalize. It has no service provider, no facade, no config/rabbitmq.php. If you're a Laravel dev, plan on either (a) reading the source to lift the patterns, or (b) using php-amqplib directly (or vladimir-yuldashev/laravel-queue-rabbitmq) and only borrowing concepts from here.

Minimal steps if you are actually on Symfony2 (or a legacy app you're maintaining):

1. composer require wanupsml/rabbitmq-bundle — then verify the package actually resolved. With 0 stars and 0 dependents, treat the install itself as an unknown; unpack vendor/wanupsml/rabbitmq-bundle and read composer.json first.
2. Register the bundle in app/AppKernel.php:

   new Wanupsml\RabbitMqBundle\WanupsmlRabbitMqBundle(),
   

   (confirm the exact class name in RabbitMqBundle.php at the repo root — forks frequently rename the bundle class but leave internal namespaces alone.)
3. Configure app/config/config.yml with the wanupsml_rabbit_mq (or whatever the alias turns out to be) key: connections, producers, consumers.
4. First use case: the canonical "hello world" — declare one producer bound to an exchange, one consumer with an callback service that implements a ConsumerInterface. Publish from a controller via the injected producer service; run the consumer with app/console rabbitmq:consumer <name>.

Where to look first in the source:

• DependencyInjection/Configuration.php — this is the source of truth for every config key. Read it before reading any docs, because docs are almost certainly nonexistent.
• DependencyInjection/*Extension.php — tells you the real service IDs (wanupsml_rabbit_mq.producer.<name> etc.).
• RabbitMq/ (or OldSound/RabbitMq/ if this is a fork) — the Producer, Consumer, RpcClient classes you'll actually subclass or wrap.

Implementation Patterns

Producer via DI (Symfony-native). Everything is a service. In a controller:

$producer = $this->get('wanupsml_rabbit_mq.producer.my_producer');
$producer->publish(json_encode($payload), 'routing.key');

No facades, no helpers. Service IDs are derived from the keys you set in config, so the config is effectively your public API.

Consumer as a callback service. A consumer config points at a service ID; that service gets execute(AMQPMessage $msg) called per delivery. This is the cleanest integration point — treat it as a thin adapter that deserializes and delegates to a domain handler, so you can unit-test the handler without RabbitMQ.

Multiple connections / vhosts. Define several entries under connections and reference them per producer/consumer. This is useful for isolating a high-throughput queue from a transactional one; it's the one feature that genuinely justifies a bundle over raw php-amqplib.

RPC pattern. The bundle ships an RpcClient/RpcServer pair (inherited from the upstream oldsound/rabbitmq-bundle lineage). If you need request/reply, look for these classes rather than hand-rolling correlation IDs.

Laravel port pattern. Don't try to boot the bundle. Instead:

1. Copy the Configuration.php shape into config/rabbitmq.php.
2. Register a singleton Producer per connection in a RabbitMqServiceProvider.
3. Wrap the consumer loop in an Artisan command (php artisan rabbitmq:consume) so you get supervisor + artisan ergonomics for free.
4. Keep the message envelope identical to what the Symfony side uses if the two apps must interoperate.

Graceful shutdown. Consumers are long-running. Wire pcntl_signal(SIGTERM, ...) to stop the consume loop after the in-flight message completes; the bundle's stock consumer loop typically doesn't do this for you, so you'll add it in a subclass.

Gotchas and Tips

Zero-stars / zero-dependents is the headline risk. No community, no issue triage, no security advisories, no upgrade path. Pin the exact version in composer.json and vendor the source into your repo if this must live in production. Assume the maintainer will never merge your PR.

Almost certainly a fork of oldsound/rabbitmq-bundle. Check whether internal namespaces are still OldSound\... while the package is Wanupsml\.... Mixed namespaces are the most common source of "class not found" after install, and they break class_exists-based autoconfiguration.

Symfony2-only. If you're on Symfony 4+, this bundle predates autoconfiguration and the AbstractBundle API. You'd be fighting AppKernel, config.yml instead of config/packages/*.yaml, and the old service-container compiler passes. On a modern Symfony app, don't use it — use php-amqplib directly or a maintained alternative.

Config quirks. Producers and consumers reference each other by name, not class. Renaming a producer in config silently breaks any service that fetched the old ID. auto_setup_fabric (if present) is convenient in dev and dangerous in prod — it declares exchanges/queues at startup and can mask topology drift. Set it false in production and manage topology out-of-band.

Debugging workflow.

• Enable the RabbitMQ management plugin (rabbitmq-plugins enable rabbitmq_management) and watch the queue depth and consumer count live — this catches 90% of "messages not arriving" issues.
• rabbitmqctl list_queues name messages consumers to confirm your consumer is actually bound.
• Set the bundle's logger (it usually takes a PSR-3 logger) to debug and watch for AMQPConnectionException — those are connection-lifecycle bugs (stale connection after broker restart) far more often than auth or routing bugs.
• Consumers silently dying on AMQPChannelException is common; make sure your execute() catches and logs rather than letting the loop exit.

Extension points. Subclass the stock Producer for retry/backoff logic; subclass Consumer to add signals, metrics, or a max-message counter (--max-messages style flags are typical and usually already wired via the console command). For custom exchange types (headers, delayed-message), you'll drop to php-amqplib's AMQPExchange/AMQPQueue directly — the bundle's abstracted producer rarely covers exotic topologies.

Laravel-specific tip. Even if you never use this bundle, its Configuration.php is a reasonable checklist for what a RabbitMQ integration needs: connection, exchange, queue, routing key, QoS/prefetch, callback service, idle timeout. Steal that shape for config/rabbitmq.php and you'll save yourself a week of discovering the knobs one production incident at a time.