Some more Documentation please

[nmn]

Would like to know the answers/documentation for the following questions:

1. Some of the examples don't mention a RabbitMQ Url. Can servicebus work without RabbitMQ, or is that just for example purposes.
2. RabbitMQ supports temporary or persistent queues. How can we use persistent queues with service bus.

If Yes:

3. In the case of a simple pub/sub model, is there a way to persist all published messages on RabbitMQ. And later be able to 'replay' all previously published messages before catching up to live?

Thanks.

[mateodelnorte]

1. servicebus is built to work with rabbitmq. if amqplib is compatible with other brokers, servicebus will work with them just as well - but they haven't been tested.
2. persistent queues are used by specifying { ack: true } as an option to sends, subscribes, and listens. in the case of sends and listens, a sender or listener specifying { ack: true } will cause the queue to be asserted as durable. messages sent will also be persistent. in the case of publish and subscribe, only the subscriber needs to specify { ack: true } in order to make the resulting queue durable.

[mateodelnorte]

Happy to update the docs to be clearer - even happier to merge a pull request with improved docs.

[nmn]

Thanks for the clear answer. Please let me know about question 3 as well. When using ack: true and persistent queues, is it possible to later set up a new listener on the queue that can read all past events?

Thanks.

[mateodelnorte]

Number 3 is not possible by default, simply due to the nature of rabbitmq.

Rabbit will forward or store and forward (based on your persistence settings) messages via exchanges and queues. Once it has forwarded those messages to any/all bound consumers, it's done with them. If using ack:true, the messages will be in a sent state and removed from the queue completely when you ack() or reject().

If you want the ability to replay messages, you would need an application-specific storage mechanism on the sender, which you could trigger to resend events via a message sent to that service from another.

If you want something like that at the infrastructure level, instead of the application level, check out kafka.

[mateodelnorte]

You may also be able to implement a custom exchange type in RabbitMQ, thus getting the ease of use of rabbit with some other features usually only found on other broker technologies.

https://github.com/videlalvaro/rabbitmq-recent-history-exchange

[nmn]

Thanks a ton!