Connection management for rabbitmq client
Node js Rabbit MQ client which has connection management backed into it. This project is written on top of amqp-connection-manager.
NOTE
Version 3 is a major and breaking change from Version 2. Please use appropriate version for your use.
Features
- Automatically reconnect when your amqplib broker dies in a fire.
- Round-robin connections between multiple brokers in a cluster.
- If messages are sent while the broker is unavailable, queues messages in memory until we reconnect.
- Very un-opinionated library - a thin wrapper around amqplib.
Configuration
host: processenvPUBSUB_RABBITMQ_SERVICE_HOST port: processenvPUBSUB_RABBITMQ_SERVICE_PORT_AMQP || 5672 username: processenvRABBITMQ_USERNAME password: processenvRABBITMQ_PASSWORD prefetch: processenvPREFETCH_JOBS || 2 vhost: processenvVHOST || '/' heartbeatInterval: processenvHEARTBEAT || 5 reconnectTime: processenvRECONNECT_TIME || 10 protocol: processenvRABBITMQ_PROTOCOL || 'amqp' defaultQueueFeatures: durable: true options: // options.findServers(callback) is a function which returns one or more servers to connect to. This should return either a single URL or an array of URLs. This is handy when you're using a service discovery mechanism such as Consul or etcd. Instead of taking a callback, this can also return a Promise. Note that if this is supplied, then urls is ignored. findServers // options.connectionOptions is passed as options to the amqplib connect method. connectionOptions
Usage
Using yarn: yarn add node-rabbitmq-client@3.0.0
OR
Using npm: npm install node-rabbitmq-client@3.0.0
;// (OR)const RabbitMQClient = ; // instantiate a client objectconst client = config; /* to publish a message */// `data` is JS objectclient; /* to consume from a queue */client; /* to purge a queue */client; /* to ack all messages */client;
Please read this for implementing consume
promiseHandler
for consume should always return a resolved Promise even if some operations on the received message fails.- When returning a resolved Promise, parameters need not be passed to it.If passed, these are simply ignored.
- Best practice is to implement a catch handler for the
promiseHandler
and push to some other queue and return a resolved Promise from there. - If parsing the JSON message fails while consuming, a rejected promise is thrown and needs to be handled appropriately (This is optional. Whether or not queue is provided, the error will be logged);
promiseHandler
gets the message and the options that were passed to consume intially
/** * options is the object which is passed to consume at the time of initialization { queue: { name: 'some-queue-name', messagePriority: message priority (1-10), // set if the queue is a priority queue. It is optional options: { arguments: { 'x-max-priority': queue priority (1- 10) // set to make the queue a priority queue. It is optional } } } } */ ;