Resuming consumption of messages from a previously created durable subscription

[BaljeetGitMaersk]

Hi Experts, we are new to RabbitMQ and trying to build the same in our organization. challenge we are seeing in our POC is,

1. we are going to use AMQP 1.0 the
2. publisher would be using topic to send the message.
3. now there are multiple subscriptions created to that topic .

here are 3 issues we are seeing

1. all new consumers subscribing to that topic are coming up with an autogenerated name and that getting hard to identify the consumer
2. if any of consumer goes down for some maintenance reason, as soon as consumer comeup - it does not Resuming consumption of messages from that topic. is there a way we can handle this.
3. if MQ instance is down, how to topic shoudl retry and ensure to send message as soon as it come up..

pls advise and these are show stopper for us..

[lukebakken]

I brought this question to @kjnilsson 's attention and he stated this -

it would be better for them to use a static topology with durable queues if they don’t want to miss messages https://github.com/rabbitmq/rabbitmq-amqp1.0#routing-and-addressing

Since there is no way to create queues or exchanges explicitly using AMQP 1.0 you'll have to use AMQP 0.9.1 or the HTTP API to create your topology in advance.

[BaljeetGitMaersk]

Hi @lukebakken - thanks for your response. we suspected same and was wondering how this can be implemented with 1.0 version. We do have hard restriction to use AMQP 1.0 and thats where are coming up with few challanges to adopt RabbitMQ.

As we are trying to introduce RabbitMQ as middleware plateform for a organization, it would be really hard to have this dedicated to each application and this will not solve purpose of "One Messaging Plateform"

Can you please also check for question 1 and 2 as those seems to be feasible( are feasible in 0.9.1) but somehow did not find a way for 1.0.

I know it will be a strange question but how this 1.0 version provide some limited functionlaity over its previous version. logically that should come up with more options.

[lukebakken]

I know it will be a strange question but how this 1.0 version provide some limited functionlaity

AMQP 1.0 is a completely different protocol that is pretty much unrelated to AMQP 0.9.1. If you have a restriction to use AMQP 1.0 I suggest you learn as much about the protocol as possible.

if any of consumer goes down for some maintenance reason, as soon as consumer comeup - it does not Resuming consumption of messages from that topic. is there a way we can handle this.

Your consumer must be written to handle disconnections and re-connect. We don't know which AMQP 1.0 client library you are using so I can't check what it's features are.

all new consumers subscribing to that topic are coming up with an autogenerated name and that getting hard to identify the consumer

I do not know if AMQP 1.0 supports specifying a consumer name (@kjnilsson ?). You will have to check your client library documentation.

[andyyeh-maersk]

Ideally though, even when the exchange to queue bindings are dynamically created via AMQP1.0 the same consumer (identified by a combination of containerId on the Open object of the Connection and the name on the ReceiverLink and topic string - at least this is how other brokers supporting AMQP 1.0 seem to do it) should be able to re-connect and resume consumption from a previously created durable subscription. In RabbitMQ AMQP1.0 support though a random queue name is generated for the amqp.topic binding for the consumer so there is no way to "reconnect" to it using the same AMQP 1.0 consumer client (e.g. a new binding and queue is generated every time the same consumer is stopped and started):

Example: Consumer AMQP1.0 client creating a receiver link with ContainerId = "subclient-1", ReceiverLink name = "sub-1", topic = ""/topic/test.amqp.#"". Start and stop the consumer 2 times results in:

Otherwise, as was mentioned, dynamically making durable subscriptions to topics is not usable and bindings and queues will have to be pre-defined before the apps/services can be deployed. This could present additional deployment/usage difficulties in certain scenarios.

[lukebakken]

@kjnilsson, who is the expert on RabbitMQ's AMQP 1.0 support, pointed me to this document:

https://github.com/rabbitmq/rabbitmq-server/tree/master/deps/rabbitmq_amqp1_0#limitations-and-unsupported-features

Durable subscriptions are not supported by RabbitMQ. I'm currently investigating if that's the same thing as "link recovery".

At any rate, you will have to pre-define your topology.

[michaelklishin]

You can also use [Definition Import](https://rabbitmq.com/definitions.html to set up a topology.