Activemq Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package, so the first decision is whether you are evaluating it inside a Symfony app or trying to bolt it onto Laravel. In a Laravel codebase the honest answer is: don't. Install the underlying stomp-php client instead and treat this repo as a reference implementation of the producer/consumer pattern. If you are in Symfony:

1. composer require overblog/activemq-bundle (expect to pin old transitive deps — last release was March 2018).
2. Enable Overblog\ActiveMqBundle\OverblogActiveMqBundle in AppKernel (Symfony 2/3 era) or bundles.php (Symfony 4).
3. Configure a connection, a producer, and a consumer under the overblog_active_mq key, pointing at your broker's STOMP transport (default port 61613), not OpenWire (61616).
4. Look first at DependencyInjection/Configuration.php — it is the real documentation for the bundle. Every option you can pass lives there.
5. First use case: publish a message to a queue from a controller or command ($producer->send('queue/orders', $json)), then consume it with the bundle's console command in a separate long-running process.

Before writing any code, confirm the broker has a STOMP connector enabled:

<transportConnector name="stomp" uri="stomp://0.0.0.0:61613"/>

Implementation Patterns

Producer-per-use-case. Define each logical producer in config rather than sharing one generic producer. This keeps queue naming, persistence, and priority settings declarative:

overblog_active_mq:
    connections:
        default:
            host: "%activemq_host%"
            port: 61613
    producers:
        order_events:
            connection: default
            destination: /queue/order.events
            persistent: true
    consumers:
        order_events:
            connection: default
            destination: /queue/order.events
            callback: app.order_consumer

Inject the producer service, don't build one. The bundle exposes each producer as overblog_active_mq.producer.<name>. Inject that into your service or job class and call send($destination, $body, $headers). Keeping this as a thin adapter around an interface lets you swap to a real queue driver later without touching domain code.

Run consumers out-of-band. The consumer is a console command intended to run under Supervisor/systemd, not in the web request cycle. One process per queue, restart on deploy, and log to a file the broker can be correlated against. For Laravel users replicating this: a queue worker command plus stomp-php's subscribe()/readFrame() loop is the equivalent.

Request/reply. For synchronous integrations with a legacy Java/.NET system, publish to a request queue with a reply-to header pointing at a temporary queue, then block on the reply. Wrap this in a timeout and a circuit breaker — STOMP gives you no built-in RPC semantics.

Fan-out and DLQ. Use topics (/topic/...) for broadcast and rely on the broker's DLQ/redelivery policy rather than implementing retries in PHP. Set activemq.redeliverypolicy.maximumRedeliveries on the broker and let poison messages land in ActiveMQ.DLQ.

Integration tip for Laravel devs: if you must interoperate with an existing ActiveMQ estate, use stomp-php directly and mirror the bundle's structure — a Producer class per destination, a Worker command that wraps the subscribe loop, and config in config/activemq.php. You get 90% of the value without the Symfony coupling.

Gotchas and Tips

• It is abandoned. Last release 2018, 10 stars, 0 dependents. No PHP 8 support, no security patches, and the old fusesource/stomp-php API is now stomp-php. Treat it as a design reference, not a dependency you ship to production.
• STOMP, not OpenWire. The most common failure is pointing the bundle at port 61616. It will hang, not error clearly. Use 61613 and verify with telnet host 61613 before blaming the code.
• Ack mode is the silent killer. Default ack behavior differs between STOMP versions; client acks mean a crashed worker redelivers, auto means messages are lost on failure. Confirm the mode in config and test by killing the worker mid-message.
• Long-running consumers leak. STOMP connections drop silently behind NAT/load balancers. Enable heartbeats on both broker and client, and add a --time-limit restart strategy via Supervisor so workers recycle.
• Debugging: set debug: true on the connection (or stomp-php's debug flag) to log raw frames; combine with the ActiveMQ web console (/admin) to inspect queue depth and DLQ. If messages vanish, check that persistent: true is set — non-persistent messages are dropped on broker restart.
• Config quirk: producer/consumer service IDs are derived from config keys, so renaming a producer silently breaks existing injections. Grep for the old service ID before merging.
• Extension points: custom consumers are wired via the callback option pointing at a service implementing __invoke/execute; that service is the right place for your retry, metrics, and dead-lettering logic rather than the bundle itself.
• Upgrade path: if you inherit a project using this, plan a migration to enqueue/amqp or Symfony Messenger with a STOMP/AMQP transport. Budget for it early — the bus-factor here is effectively zero.