0

For example, we want to pass some of our information to third-party API. We can't rely when this API would go down i.e. network error. So, we have two choices:

  1. Log failures of the request being pushed in this API and try pushing them through some scheduled job - Issue is what if some of these requests failed due to API being down, we need to repush these failed requests too and this would go on an on.
  2. Use something like Rabbitmq dead letter mechanism- You can use its retrial mechanism for failed requests but this adds to maintenance and what if it fails even after multiple dead-letter retrials?

How should we deal such third API processes and push the failed requests again?

Sahil Sharma
  • 3,847
  • 6
  • 48
  • 98
  • Your two options are not mutually-exclusive, and option 2 really doesn't make any sense. Hopefully my answer clears up some confusion. – theMayer Nov 29 '17 at 05:28

1 Answers1

1

So, RabbitMQ dead-lettering is not the same thing as a negative acknowledgement, though they can be related.

The scenario you are describing (assuming that I understand it correctly- your description is very abstract) is a fairly common situation, and can be described by the following sequence of events:

  1. Processor takes message from queue
  2. Processor attempts to process message
  3. Processor fails to process message
  4. ?

The question is what to do at step 4. In many applications, step 4 is to drop the message. However, RabbitMQ allows for the use of negative acknowledgements in this situation, which tell the broker that the message could not be processed. The broker, in turn, can place the message back at the head of the queue. There is nothing to stop the same processor from picking up the message again and attempting to process it if this happens, so this should be used when the failure condition is temporary (i.e. a problem with the processor, not the message itself).

Your application processing logic would need to decide when it makes sense to pull messages from the queue and attempt to process them. For example, it might make sense to wait a pre-determined period of time, or it may be wise to poll the 3rd party API until it comes back up. What you do here is up to you.

Dead-Lettering

Now, when you reject a message (basic.nack), you can control whether RabbitMQ dead-letters the message by specifying requeue=false. If requeue is false, then the message will be dead-lettered (or dropped, if there is no dead letter exchange configured).

A dead-letter queue is just that - it's a place where messages go to die. As a general rule, it should never make sense to connect your ordinary processors to this queue because, by definition, the reason messages were there in the first place is that they could not be processed- ever. So, if you intend for the condition to be temporary (i.e. a down server), requeue the message and stop processing more messages until the condition is resolved. If, on the other hand, there is a problem with the message, then by all means dead-letter it.

theMayer
  • 15,456
  • 7
  • 58
  • 90
  • so, you suggest we should use rabbitmq requeue mechanism here i.e. stop process until things are normal? But isn't it overhead as we are hitting many third party APIs and for all those API calls, we will have to create separate consumer – Sahil Sharma Nov 29 '17 at 06:03
  • I don't know how your processor processes messages, and for each message, that is not really relevant to the overall system behavior. The idea is that if there is a problem with the processing ability, then you stop consuming messages and requeue any that couldn't be processed. It does not make sense to keep trying to process if there is a problem with the processor. – theMayer Nov 29 '17 at 06:04
  • I think there's some confusion here- my question is not whether we should keep on retrying OR stop consuming process BUT should we directly hit third party API from our servers and log the errors somewhere OR hit it through rabbitmq to use this requeue process? – Sahil Sharma Nov 29 '17 at 06:07
  • What do you mean “hit it through rabbitmq?” – theMayer Nov 29 '17 at 06:23
  • If what you’re saying is that the status of the 3rd Party API is/can only be evaluated when a message is attempted to be processed, then if that’s an external constraint, so be it. But I would find that to be quite odd. Ordinarily, a given component in a system is responsible for “self-check” to make sure it can actually do its job- including checking any dependencies. – theMayer Nov 29 '17 at 06:24