Skip to content
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

unknown delivery tag issue #155

Open
vinayk047 opened this issue May 2, 2018 · 0 comments
Open

unknown delivery tag issue #155

vinayk047 opened this issue May 2, 2018 · 0 comments

Comments

@vinayk047
Copy link

I've consumer in cluster mode which acks after performing the task. but after certain number of messages it stops receiving the messages and when i check the rabbit mq log. i see following error message.

operation basic.ack caused a channel exception precondition_failed: unknown delivery tag

DavidWittman pushed a commit to DavidWittman/foo-foo-mq that referenced this issue Jul 20, 2020
Send channel failures up to the connection so that they can be handled
appropriately. Previously, errors on channels caused silent failures
which could result in queues being unable to receive messages without
any indication of failure, such as described in
arobson#155.

This approach is a bit naive in that it causes the whole connection to
fail when an a single channel fails, but I don't think the abstractions
in this library allow for the user to respond to channel-level events.

In my case, this type of failure occurred any time my consumers lost
their connection to the RabbitMQ cluster and tried to send an ack for an
old delivery tag to a different RMQ node in the cluster (i.e. queue is
re-established on new node and batch acks send after reconnecting). This
would result in the following error in amqplib:

    Error: Channel closed by server: 406 (PRECONDITION-FAILED) with message "PRECONDITION_FAILED - unknown delivery tag 42"

But from the perspective of foo-foo-mq/rabbot, everything was fine. With
these changes in place, I can at least listen for a `failed` event on
the broker and respond appropriately.
DavidWittman pushed a commit to DavidWittman/foo-foo-mq that referenced this issue Nov 26, 2023
Send channel failures up to the connection so that they can be handled
appropriately. Previously, errors on channels caused silent failures
which could result in queues being unable to receive messages without
any indication of failure, such as described in
arobson#155.

This approach is a bit naive in that it causes the whole connection to
fail when an a single channel fails, but I don't think the abstractions
in this library allow for the user to respond to channel-level events.

In my case, this type of failure occurred any time my consumers lost
their connection to the RabbitMQ cluster and tried to send an ack for an
old delivery tag to a different RMQ node in the cluster (i.e. queue is
re-established on new node and batch acks send after reconnecting). This
would result in the following error in amqplib:

    Error: Channel closed by server: 406 (PRECONDITION-FAILED) with message "PRECONDITION_FAILED - unknown delivery tag 42"

But from the perspective of foo-foo-mq/rabbot, everything was fine. With
these changes in place, I can at least listen for a `failed` event on
the broker and respond appropriately.
zlintz pushed a commit to Foo-Foo-MQ/foo-foo-mq that referenced this issue Jan 25, 2024
Send channel failures up to the connection so that they can be handled
appropriately. Previously, errors on channels caused silent failures
which could result in queues being unable to receive messages without
any indication of failure, such as described in
arobson#155.

This approach is a bit naive in that it causes the whole connection to
fail when an a single channel fails, but I don't think the abstractions
in this library allow for the user to respond to channel-level events.

In my case, this type of failure occurred any time my consumers lost
their connection to the RabbitMQ cluster and tried to send an ack for an
old delivery tag to a different RMQ node in the cluster (i.e. queue is
re-established on new node and batch acks send after reconnecting). This
would result in the following error in amqplib:

    Error: Channel closed by server: 406 (PRECONDITION-FAILED) with message "PRECONDITION_FAILED - unknown delivery tag 42"

But from the perspective of foo-foo-mq/rabbot, everything was fine. With
these changes in place, I can at least listen for a `failed` event on
the broker and respond appropriately.

Co-authored-by: David Wittman <[email protected]>
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

No branches or pull requests

1 participant