Treat a released outcome for a topic send as a successful send - #74
Open
ansd wants to merge 1 commit into
Open
Conversation
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.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ansd
changed the title
released outcome for a topic send as a successful send
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.