Support custom message container hook #10050
Labels
Comments
ansd
added a commit
to ansd/rabbitmq-server
that referenced
this issue
Dec 6, 2023
as done by mc_amqpl:protocol_state/2 and mc_amqp:protocol_state/2 We do not include that commit in 3.13 for now as there is no real use case for it: Quorum queue client sets x-delivery-count and stream queue client sets x-stream-offset. The MQTT plugin does not consume directly from streams, hence there is no need to set x-stream-offset. Whether the message is a redelivery from quorum queues is encoded already in the DUP flag of the MQTT PUBLISH packet. Also, if source and destination protocols are both MQTT, we must obey: > The Server MUST send all User Properties unaltered in a PUBLISH packet when forwarding the Application Message to a Client. We do know if the source protocol was MQTT in mc_mqtt:protoco_state/2 by checking whether `Topic =/= undefined`. However, given we don't have a good use case in 3.13, let's not add x-* annotations as user property. We park this commit on a branch in case we need it in the future, e.g. for rabbitmq#10050
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
It may be desirable to store arbitrary annotations when receiving from a source protocol such that these annotations will be available when consuming.
Describe the solution you'd like
AMQP 0.9.1 channel, MQTT connection, AMQP session, STOMP connection should provide a hook where the message container and the channel state / MQTT processor state / AMQP session state / STOMP processor state are passed in. Then 3rd party implementations can set whatever annotations they want and they will be picked up automatically when consuming from a different protocol:
headersx-*annotations will be set as message annotationsDescribe alternatives you've considered
Somewhat related to #10051
Additional context
This allows for use cases such as https://groups.google.com/g/rabbitmq-users/c/gPJxxG2PGXM/m/EF2BDwpIAQAJ
For MQTT this pluggable message container approach gets called at the same place as
rabbitmq-server/deps/rabbitmq_mqtt/src/rabbit_mqtt_processor.erl
Line 1555 in f54f880
rabbit_message_interceptor. This hook gets as input the message container and the MQTT processor state. The 3rd party implementation could add here the MQTT client ID as annotation. Therefore the MQTT client ID will be available when receiving via AMQP 0.9.1The text was updated successfully, but these errors were encountered: