NServiceBus Retry Delay

前提是你 提交于 2019-12-04 05:40:50
Andreas Öhlund

The NSB retries is there to remedy temporary problems like deadlocks etc. Longer retries is better handled by creating another process that monitors the error queue and puts them back into to the source queue at the interval you like. Take a look at the ReturnToSourceQueue.exe that comes with NSB for reference.

Edit: NServiceBus now supports this , we call it Second Level Retries, see http://docs.particular.net/ for more details

Here is a blog post on why NServiceBus doesn't include a retry delay that I wrote after asking Udi this very same question in his distributed systems architecture course:

NServiceBus Retries: Why no back-off delay?

And here is a discussion thread covering some of the points involved in building an error queue monitor/retry endpoint:

http://tech.groups.yahoo.com/group/nservicebus/message/10964

As far as HandleCurrentMessageLater(), all that does is puts the current message back at the end of the queue. If there are no other messages waiting, it's going to be processed again immediately.

SDShooter

As of NServiceBus 3.2.1, they provide an out of the box solution to handle back off delays in the event of consecutive message failures. The previously existing retry mechanism still retries failures without a delay to handle cases like Database deadlocks, quickly self healing network issues, etc.

Once a message has been retried the configured number of times, the message is moved to a "Second Level Retry" queue. This queue, as configured below, will retry after a 10, 20, and 30 second delay, then the message will be moved to the configured error queue. You're free to change these values to something that better suites your environment.

You can also check out this link: http://docs.particular.net/nservicebus/second-level-retries

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!