AMQP sending to RabbitMQ with 1.0 Plugin doesn't respect durable setting

[BiggA94]

Hi,
I'm trying to use the reactive-messaging-amqp library in order to send AMQP messages via RabbitMQ. I use the AMQP 1.0 plugin for rabbit.
The Application succeeds to connect and generate the Queue.
But when it tries to send a Message to this queue, I can see the following error message in the logs of Rabbit:
{'v1_0.error',{symbol,<<"amqp:precondition-failed">>},{utf8,<<"PRECONDITION_FAILED - inequivalent arg 'durable' for queue 'prices' in vhost '/': received 'true' but current is 'false'">>},undefined}

This prevents me from sending Messages to durable queues (non-durable queues are working fine).

I have created a sample project using Quarkus:
Quarkus-Native-Test

The PriceGenerator contains the message generator.

Used Java version: openjdk 11.0.2, windows

[cescoffier]

Looking at: https://stackoverflow.com/questions/51385700/inequivalent-arg-durable-for-queue, did you try to:

• not create the queue
• create the queue but marked as non-durable

[BiggA94]

* not create the queue

The Queue gets created from reactive-messaging-amqp, I don't create it myself.
But I have also tried Creating the Queue manually before starting the service. it doesn't work either.

* create the queue but marked as non-durable

Like I said, non-durable queues are working fine.

[cescoffier]

@BiggA94 I got a response from @gemmelr:

If I'm interpretting the text correctly I think its likely failing
inside the broker due to applying some AMQP 0-x style behaviour to the
1.0 bits in a way I wouldnt say is expected for a couple reasons.

I think in this case it is perhaps using the 'terminus durability' to
be a direct equivalent of the old 0-x queue 'durable' flag, which it
isnt (since unlike AMQP 0-x, 1.0 does not detail queue/etc node
details, beyond simply their address), and then further enforcing that
a link with non-durable terminus-durability cant attach to the address
of a durable queue. Thats unexpected to me since terminus durability
isnt queue (which is a node, rather than a terminus) durability. Also,
the AMQP 1.0 spec says that in the case the two peers disagree about
'requested' and 'actual' terminus details, a peer (e.g the broker)
should not preempt whether the actual details are acceptable to the
other party (e.g the client), which it seems is exactly what the
broker did in this case (which is what tended to occur in AMQP 0-x).

So I would need to try it to check what can go wrong.

[misl]

I am running into the same issue when using RabbitMQ as broker. However I do see some strange behavior.

Started with a RabbitMQ without any queues yet. My Quarkus application uses 2 queues. One for reading and one for writing. Both are configured in application.properties to be durable. The queue for reading is indeed created with durability (according to RabbitMQ management console). The write queue however is created WITHOUT durability. Why would that be?

[cescoffier]

The AMQP connector is for AMQP 1.0, not for RabbitMQ.
We would need a specific RabbitMQ connector.

[misl]

I understand, but RabbitMQ has an AMQP 1.0 plugin and things actually work except for the durability issue.

[cescoffier]

Yes, but it does not seem to handle everything. See this comment: #174 (comment)

[andreas-eberle]

I experience this problem with Quarkus. I have a service that is pushing messages into the queue and one that consumes the messages. Both have equivalent application.properties like the following:

amqp-host=${AMQP_HOST}
amqp-port=${AMQP_PORT:5672}
amqp-username=${AMQP_USERNAME}
amqp-password=${AMQP_PASSWORD}
mp.messaging.outgoing.trigger-training.connector=smallrye-amqp
mp.messaging.outgoing.trigger-training.address=trigger-training
mp.messaging.outgoing.trigger-training.durable=true

The only difference is that on service has the configuration for outgoing, the other has it for incoming.

When I now start the outgoing service first and add a message to the queue, the queue is created in my RabbitMQ as non-durable, although I specified it to be durable.

In contrast, when I start the incoming service first, the queue is created as durable.

The result is that the respective other service cannot connect to the queue since the durable setting does not match.

From this experience, I guess that the durable setting is somehow not respected when set for an outgoing connection and falls back to the default false value.

Is there another workaround than just setting the queues to non-durable for now?

[Legion2]

The documentation does not tell us what durable mean, it could mean, it's a durable queue or the messages send are durable or it's a durable subscription. From the observed behavior it looks to me that it mean durable subscription, because a durable subscription require a durable queue. This also means, durable has no meaning for outgoing channels.

[cescoffier]

I have rewritten the documentation. I will make sure it’s clear. It actually depends if you are receiving or sending. On the reception side, it means durable subscription. On the sending side, it’s about message durability.

…

On 30 Mar 2020 at 19:17 +0200, Leon Kiefer ***@***.***>, wrote: The documentation does not tell us what durable mean, it could mean, it's a durable queue or the messages send are durable or it's a durable subscription. From the observed behavior it looks to me that it mean durable subscription, because a durable subscription require a durable queue. This also means, durable has no meaning for outgoing channels. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[Legion2]

I used the durable option for sending to an activemq artemis broker, but the messages in the queue have the durable attribute set to false. I basically used the config example from https://smallrye.io/smallrye-reactive-messaging/

[cescoffier]

In this case, I don’t believe it applied durability. I guess it uses your broker config.

…

On 30 Mar 2020 at 19:36 +0200, Leon Kiefer ***@***.***>, wrote: I used the durable option for sending to an activemq artemis broker, but the messages in the queue have the durable attribute set to false. I basically used the config example from https://smallrye.io/smallrye-reactive-messaging/ — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[cescoffier]

Closing - out of date.