-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Send field when user sets durable=false
#330
Comments
According to the AMQP 1.0 spec, the absence of a value MUST be interpreted as the default value which would be "unless other target or node specific defaults have otherwise been set" I believe this means that when creating the link, a different default can be specified. I suspect this ties in with the target's durability setting but am not 100% sure. Are you setting |
Thank you for your reply @jhendrixMSFT.
I'm not.
Possibly. The spec is very vague here. The "safest" Terminus Durability setting is
Since Terminus Durability is only about the unsettled state, and not about whether the message itself is durable (e.g. written to disk by the target queue), I don't think the spec refers to Terminus Durability.
I interpret this sentence in the spec as follows: Nodes, for example queues in messaging brokers, can decide themselves what the default value for RabbitMQ 4.0 interprets That said, a client app should still be able to overwrite the default by explicitly allowing a message to be non-durable. If the client app using this Go client lib explicitly sets the message as non-durable, I'd wish that this Go lib explicitly sets and marshals the To sum up:
|
Since We do have one rough edge here though. The zero-value for |
Thanks.
This sounds great, yes.
All header fields are optional according to the AMQP spec.
(But yeah, it breaks the API unfortunately.) |
When
durable=false
, thedurable
field is omitted ingo-amqp/message.go
Line 331 in 1003610
This complies with the spec given that the spec defaults to
false
for durable.However, the spec also mentions:
This means that brokers could set other defaults.
RabbitMQ 4.0 interprets
durable
astrue
by default to be safe by default.Beginners could easily forget setting the
durable
field totrue
resulting in unexpected message loss. This applies to all brokers, not only RabbitMQ.Hence, I suggest that this client lib should explicitly send the
durable
field when the user sets this field tofalse
to allow RabbitMQ to store the message non-durable (if explicitly requested by the user).In other words, do not omit this field when marshalling.
You could use pointers to differentiate between field is set vs field is unset.
The performance penalty of sending this field is negligible.
The text was updated successfully, but these errors were encountered: