[ansd]

Publishing to a JMS topic that currently has no matching subscription failed with "Delivery failed: released by receiver" instead of succeeding.

A released outcome is not an error signal. AMQP 1.0 section 3.4.4 defines it at the target as indicating "that a given transfer was not and will not be acted upon", in contrast to rejected ("an invalid and unprocessable message") and modified. A broker that fans a topic publish out to zero subscriptions has done exactly that: nothing acted on the transfer, and there is nothing wrong with the message.

The Jakarta Messaging pub/sub model expects the send to succeed in that case. Section 4.2.2 states that a subscription receives a copy of a message sent to the topic only while the subscription exists, and that a non-durable subscription only exists while it has an active consumer, so a message published to a topic with no matching subscription is simply discarded. This is normal operation, not a send failure, and it is common: it happens for a temporary topic with no subscriber, after a subscriber is closed, and when a durable subscription's selector no longer matches.

Complete the send successfully when the released delivery was addressed to a topic. A queue is left reporting the failure as before: there, a released outcome means the message was not stored, and silently succeeding would lose a point-to-point message without telling the application.

[gemmellr]

I dont really agree with the premise here, so this will not be made to happen by default. I am willing to have this behaviour available upon request by configuration, but not by default.

The client was asked to send a message, and is told the message was not accepted, i.e it was not sent. The client has no way to know why the message was not-sent/released, and its definitely not its place to guess at the meaning when the result is unwittingly enabling messages to silently disappear. Thats a send failure in an API that has no way to convey the explicit state. Regardless, even if I did agree with the premise I wouldnt change the client behaviour in this way after over a decade doing the reverse when knowing it opens potential for messages to then silently disappear that did not used to, so it would still be going behind a toggle.

If the broker wants to disappear a message sent to a topic without subs it is entirely free to do so. Other brokers I'm aware of the behaviour for would either accept, or configurably accept-or-reject/modified in this situation.

This change would need a Jira.