Introduce headers when message gets dispatched to client

[c-datculescu]

Hello all.

I would like to propose the introduction of a set of custom headers that should be attached to a message when the message is delivered to a client, similar to the dead-letter headers option.

The use case for this addition will be in the case of buffered clients, there is no way to say how much time the message spent in the queue vs how much time the message actually spent in the local application cache. I think this should help in better understanding and isolating issues (currently i have people asking me whether there is a issue in RabbitMQ or in the applications we are using and i cannot say for sure when messages get delayed).

I am not sure exactly how much effort would this be since i have no knowledge of erlang whatsoever.

Thank you,
Cristian.

[michaelklishin]

If you need to add a header when a message is routed, it should be one of the easiest plugins: a custom exchange type (that otherwise mimics one of the existing ones). If you specifically want to do that when a message is actually delivered, this requires changing RabbitMQ core and is moderately difficult.

[c-datculescu]

Ok, thank you very much. I guess i can try to learn erlang a little. Adding the header when message is routed is a fine option as well, didn't really consider it.

Thank you very much for the feedback.

[c-datculescu]

@michaelklishin
One solution that crossed my mind is to enable tracing, but i am not sure about the performance downsides. At the moment the number of dispatched messages is not extremely high.

That would allow me to catch the time when message got dispatched as well.

Any thoughts about using this?

[videlalvaro]

Besides effort, AFAIK, per-spec the broker shouldn't modify messages. It should just pass messages as-is, without modifying them.

[michaelklishin]

We already add headers when dead-lettering. We never modify the body or remove user-provided headers other than BCC.

[michaelklishin]

@c-datculescu tracing effectively doubles internal message rate. It's not a very good idea for most cases (outside of development environments).

[c-datculescu]

I would not enable tracing full time. my idea was to enable it just enough to troubleshoot the issue and disable it afterwards.

Regarding dead-lettering and headers, we hit a funny issue in production. if a message is dead lettered more than 498 times, as i remember, we start getting some errors. this is an edge case that we dealt with by limiting the number of times we dead-letter, but it was a little tricky to discover the reason.

Thanks for the answers.

[videlalvaro]

That DLX issue might have been solved in the latest RabbitMQ release
On Thu, Jun 4, 2015 at 12:32 PM cristian datculescu <
notifications@github.com> wrote:

I would not enable tracing full time. my idea was to enable it just enough
to troubleshoot the issue and disable it afterwards.

Regarding dead-lettering and headers, we hit a funny issue in production.
if a message is dead lettered more than 498 times, as i remember, we start
getting some errors. this is an edge case that we dealt with by limiting
the number of times we dead-letter, but it was a little tricky to discover
the reason.

Thanks for the answers.

—
Reply to this email directly or view it on GitHub
#177 (comment)
.

[michaelklishin]

Yes, the number of x-death events is now capped as of 3.5.2, see #78 and #152.