AMQP 1.0: Consider adding (non-normative) connection properties topic-prefix and queue-prefix

[alaendle]

Is your feature request related to a problem? Please describe.

Client code should be independent from broker internals - therefore the prefixes should be encapsulated by the protocol. Unfortunately there is no standardisation of the connection properties (http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-open).
But most clients respect the mentioned prefixes (e.g. Apache.NMS.AMQP (https://github.com/apache/activemq-nms-amqp/blob/5e4e137b071101463b8083f8a8a1cddada5b6f8a/src/NMS.AMQP/Provider/Amqp/AmqpConnection.cs#L161)) and many brokers provide this information (e.g. Solace (https://docs.solace.com/API/AMQP/AMQP-Protocol-Conformance.htm#section-2-7-1-open) & ActiveMQ (https://github.com/apache/activemq/blob/4ff78ddab993d62408c8e63ce63a63d5757fe039/activemq-amqp/src/main/java/org/apache/activemq/transport/amqp/protocol/AmqpConnection.java#L209))

Describe the solution you'd like

I think it would be a good idea to include the prefix information into the transmitted connection properties:

Just to make it clear - here a response from an RabbitMQ connection:

And here Solace:

So basically I request to add topic-prefix and queue-prefix.

Describe alternatives you've considered

At least there seems to be an easy workaround - as the server properties are extensible via an environment variable:

RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS="-rabbit server_properties [{'topic-prefix',\"/topic/\"},{'queue-prefix',\"/queue/\"}]"

Additional context

Please let me know if I was unclear or if I could contribute further information!

[ansd]

Thank you @alaendle , this is a great suggestion.

But most clients respect the mentioned prefixes

Which other clients handle these properties?

[alaendle]

Thanks @ansd 😊. I was actually imprecise regarding the client software. At this point we have to differentiate between pure AMQP encapsulating libraries and libraries that have an idea of ​​topics/queues. Another example in the category of topic/queue aware libraries is Apache QPID JMS (https://github.com/apache/qpid-jms/blob/2d799c153a6b51f07a4c9ccec4a8751598183733/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpConnectionProperties.java#L112).

But therefore maybe the more interesting question is how common the two connection properties are among other AMQP 1.0 brokers, because even if a "low-level" library is used the information about the prefixes is needed - it just needs to be handled in the client code (at least if interoperating with a broker that internally uses the topic/queue concept). Would it help my feature request if I trace and add the OPEN telegrams of other AMQP brokers? Or are you already convinced 😉

[michaelklishin]

@alaendle we need to know what libraries support these properties in order to test #12541.

[ansd]

Thank you @alaendle. I was already convinced. I was just wondering out of interest which other client libs parse these prefixes. Thanks for the link to the QPid JMS client 🙂

[ansd]

After evaluating this feature, we've decided in #12541 (comment) to not add these properties at this time since they introduce more problems than they solve.

[alaendle]

Thanks @ansd for all the effort you took to analyse this in such detail; and I really have to admit that from a pure RabbitMQ perspective it is not possible to provide a solution that covers all possible usage scenarios - so leaving this problem open is maybe the best thing to do. However one last question, if I want to abstract the concrete AMQP broker from my client code - is the workaround to add these properties via environment or advanced configuration okay - or do you also see this as problematic?

RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS="-rabbit server_properties [{'topic-prefix',\"/topic/\"},{'queue-prefix',\"/queue/\"}]"

(maybe even adapted to v2-address scheme after my application become ready)

[ansd]

I think your workaround might be suitable for the v1 address formats. For the v2 address formats, the client app or an admin must make sure that the topology (queue and/or binding) gets created prior to attaching a link. (More infos on the motivation of the v2 address format can be found in #10873 (comment))