Even after successful delivery, the message may still fail during playback to the service. Such failures typically abort the playback transaction, which would cause the message to go back to the service queue. WCF will detect the message in the queue and retry. If the next call fails too, the message will go back again to the queue, and so on. Continuously retrying this way is often unacceptable. If the motivation for the queued service in the first place was load leveling, the auto-retry behavior will generate considerable stress on the service. You need a smart failure-handling schema that deals with the case when the call never succeeds (and of course, defines “never” in practical terms). The failure handling will determine after how many attempts to give up, after how long to give up, and even how often to try. Different systems need different retry strategies, and have different sensitivity to the additional thrashing and probability of success. For example, retrying 10 times, a single retry once every hour, is not the same strategy as retrying 10 times 1 minute apart, or the same as retrying 5 times, each with a batch of 2 successive attempts separated by a day. In addition, once you have given up on retries, what should you do with the failed message and what should you acknowledge to its sender?
Transactional messaging systems are inherently susceptible to repeated failure because they can bring the system to its knees. Messages that continuously ...