All geek questions in one place

When to disable message processing in the event of a queue / database failure?

This is more suitable for the normal case of an application receiving messages, storing them in a database, and possibly sending messages as a result.

  • Suppose transactional sorting sorts atomic commit; What is a good policy regarding when to close the application at all?
  • If the database crashes, the application may be flooded with messages, which will eventually be rejected. Should he immediately refuse?
  • If the outgoing message service does not work, the database will be populated with rollbacks. Again, is it better to refuse right away?

Additional points for any advice on how best to make the spring application shut down in this case, since it has a default list of listeners, it will catch any exception at runtime and continue to work.

+4
source share
2 answers

From what I understand, you are looking for the following:

  • Do not lose messages from the inbound queue just because the application cannot process them.
  • When to stop processing, if errors occur during processing.

First of all, it is important to analyze the infrastructure that you are dealing with and the situations that you will encounter. Typical downtime and how often they occur at different levels of the system. How reliable is the network, are you using a rac server, etc.

  • JMS already provides retry mechanisms. If message processing has failed, send it to the queue before the expiration date. This only makes sense in conjunction with a delay, so no flood occurs. If a slight delay does not affect the transaction, I would recommend using delayed messages. depending on your JMS provider, this is supported in the container. Using a dead letter or an exception queue when a message from an inbound queue cannot be processed can help with message loss.

  • Again, you can be the best judge of the situation. You can define a property, because the number of consecutive dead letter queues is a disconnect condition. You can configure it during system testing to avoid false positives.

+1
source

As already mentioned, cracked_all is not recommended to give up immediately.

I think the best way would be to have other databases ready to work since the primary failure. After receiving a failed confirmation, you can redirect them to a secondary one. Therefore, you do not lose so much data. In this case, you can use the "Guaranteed Delivery" feature in JMS.

With guaranteed delivery, the messaging system uses an integrated data warehouse to store messages. Each computer on which the messaging system is installed has its own data warehouse so that messages can be stored locally. When the sender sends a message, the send operation does not complete successfully until the message is stored in the sender data store. Subsequently, the message is not deleted from one data store until it is successfully sent and stored in the next data store. Thus, as soon as the sender successfully sends the message, it is always stored on disk, at least on one computer, until it is successfully delivered and confirmed by the recipient. 1

+1
source

Source: https://habr.com/ru/post/1300871/

More articles:


All Articles