Skip to content

Conversation

@manner82
Copy link

In case the queue has a message count/size limit (config "x-max-length"),
rabbitmq can be configured to nack/reject publishing messages when the
queue is full (config "x-overflow":"reject-publish").

In this setup, qamqp exchange only does a log and skips the nack message,
which leads to these delivery tags are never removed from
unconfirmedDeliveryTags vector, therefor allMessagesDelivered signal
will never trigger.

To make the library user be able to handle this (but try to maintain
compatibility), I have added an extra signal (messageDeliveryFinished)
which is also sent when rejected/nacked messages remained, identifying
the nacked messages by their delivery tags.

Also added direct signals for publish confirms / rejects, because handling
nack/reject is often just a retry of the publish after some time. This requires
storing the messages until they are confirmed. For some use cases keeping
all messages in memory until there is a point when all waiting publishes
gets confirmed is a waste of resources or not feasible at all (no time when
all is confirmed).

See https://www.rabbitmq.com/maxlength.html and
https://www.rabbitmq.com/confirms.html#server-sent-nacks

@manner82 manner82 force-pushed the PAM-5269-rabbitmq-nack-handling branch 4 times, most recently from 8de0f0d to a06fd67 Compare May 25, 2018 09:03
manner82 added 2 commits May 25, 2018 11:03
In case the queue has a message count/size limit (config "x-max-length"),
rabbitmq can be configured to nack/reject publishing messages when the
queue is full (config "x-overflow":"reject-publish").

In this setup, qamqp exchange only does a log and skips the nack message,
which leads to these delivery tags are never removed from
unconfirmedDeliveryTags vector, therefor allMessagesDelivered signal
will never trigger.

To make the library user be able to handle this (but try to maintain
compatibility), I have added an extra signal (messageDeliveryFinished)
which is also sent when rejected/nacked messages remained, identifying
the nacked messages by their delivery tags.

Also added direct signals for publish confirms / rejects, because handling
nack/reject is often just a retry of the publish after some time. This requires
storing the messages until they are confirmed. For some use cases keeping
all messages in memory until there is a point when all waiting publishes
gets confirmed is a waste of resources or not feasible at all (no time when
all is confirmed).

See https://www.rabbitmq.com/maxlength.html and
https://www.rabbitmq.com/confirms.html#server-sent-nacks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant