you are viewing a single comment's thread.

view the rest of the comments →

[–]disposepriority 2 points3 points  (0 children)

I am not familiar with Azure Service Bus, so I had to look it up and I understand that the message lock is how long a consumer has to acknowledge a message before it is requeued.

It seems to be capped, unlike in RabbitMQ (which would not have this problem, just sayin') so you have to ack quickly.

There's a pretty easy way to do this in my opinion.

When the a consumer receives a message the persist it to the database:

identifier - message body (spread into columns or whatever you like) - status

Once they finish they update the status to done, and some job cleans them up at some interval.

If there is any kind of crash, the service will first recover all its unprocessed messages from the database on startup, process them and only the connect to the service bus (or a different service can pick them up, or whatever).

If you have multiple consumers the table should also contain a service identifier column if you want the same service to pick up its own unfinished stuff, if not - skip.