Reactive Programming for .NET Developers by Antonio Esposito & Michael Ciceri

Author:Antonio Esposito & Michael Ciceri [Esposito, Antonio]
Language: eng
Format: azw3
Publisher: Packt Publishing
Published: 2016-07-29T04:00:00+00:00

Retry

Another widely used approach when experiencing unwanted behaviors from external systems or unpredictable functions is the ability to repeat our logic until we get our desired result.

This choice has its pros, such as the ability to avoid unintentional network errors or system low availability. However, the choice has its cons, such as the ability to reduce system response time, increase overall resource usage, and (the terrifying one) the possibility to duplicate data or create inconsistent data stores if we don't properly manage all repeating logics.

The most critical time in a retry logic is when an attempt fails, in other words, when we eventually need to rollback the partially saved data, the partially executed logics, or the partially sent commands (to external systems).

This doesn't mean that the retry logic is wrong in itself. It simply focuses a lot on its usage because it may bring the invisible issues. Here's a complete example (it is better to execute this example without the debugger by pressing Ctrl + F5 ):

//a finite sequence of 5 values var source = Observable.Interval(TimeSpan.FromSeconds(1)) .Take(5) .Select(x => DateTime.Now) .Select(x => { //lets raise some error if (x.Second % 10 == 0) throw new ArgumentException("Wrong milliseconds value"); else return x; }) //restart he sourcing sequence on error (max 2 times) .Retry(2) //materialize to read message metadata .Materialize(); source.Subscribe(x => Console.WriteLine(x)); Console.ReadLine();

The preceding example shows a usage of the Reply sequence available through the Reply extension method.

The execution shows that we have to produce 5 messages. If any message has a timestamp with seconds divisible by 10 an exception raises. When an exception reaches the Retry sequence, this simply closes the subscription and starts another subscription, restarting the counter of 5 messages.

At the end of the sequence construction, although we materialize the Reply sequence, we will never see the error message. We will simply receive the concatenation of all the messages before and after the error. Obviously, this may bring an unintentional hidden exception that may make it tricky to find unwanted behaviors.

The solution lies in the usage of the Materialize operator together with a filter that will let us trace only unwanted exceptions when we're running our application in the production stage. This choice will give us the ability to know when an exception occurred with a light additional resource usage. Differently, once we're trying to investigate an exception we already know, we may edit the filter to trace multiple information other than exceptions to help us find the root cause of the investigating exception.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.