In a previous post, I looked at how Rx can be used to neatly track the status of service dependencies. In this post, I’ll look at how the same technique can be used to manage streams that update with a varying frequency, and a specific application – tracking market data staleness in financial applications.
When integrating independent services to build larger systems, it’s often important for services to keep track of the status of the other services that they depend on. Especially for a microservices approach, where services should expect their dependencies can be absent at any point in time. Services that cope with dependencies being unavailable make a less flaky and more resilient, hands off system.
Services can dynamically change their behaviour as the states of their dependencies change. If a dependency is offline, a service can decide to re-route work, buffer it until processing can resume, or explicitly reject requests. Doing this proactively by reacting to changes in dependencies’ statuses makes this much more fluid.
This post will look at a simple way of using Reactive Extensions to keep track of dependency status.
I recently ran a workshop on Rx, and as part of preparing I had to hunt down some useful resources for learning. I found that things had come a long way since the early days, when people mostly learned from videos of Wes Dyer, Jeff van Gogh and Bart de Smet drawing on whiteboards at Microsoft, and Lee Campbell’s blog.
Since the initial .Net release, a lot has changed for Rx – it’s become open source, and it’s now available for many platforms: .Net, Java, Javascript, plus quite a few more. It’s also being used and talked about by some big players outside Microsoft, like NetFlix (who are responsible for the RxJava port).
With all this new exposure, there are now a lot more resources for learning Rx. Here are some that I think are particularly useful.
StackOverflow, like Wikipedia, is a dangerous place. It’s a place where you go to learn something you didn’t know you wanted to learn. In both cases, the risk is: are you going to resurface, half an hour later, much the wiser on the French Revolution, or perhaps some nitty gritty feature of the Garbage Collector? Or are you going to come out with an enhanced knowledge of the manufacturing technique used to create left handed drinking straws in the early 20th century (and the life of the mother of the creator, and the university they went to, and the wartime history of the town they grew up in)?
So it was a lucky happening that I bumped into a thread on StackOverflow a while back regarding how Math.Pow is implemented in the .Net framework. It’s one of these methods which leave you cold when you navigate to their implementation with Resharper/dotPeek – because it’s just a stub with a MethodImplOptions.InternalCall attribute on it. It’s basically a marker saying “this code is implemented with magic”.
But, as Eric Lippert says – there is no magic. Magic is just a place holder for a deeper understanding, in the same way as MethodImplOptions.InternalCall is a place holder for a lower level implementation.
The post leads on to a discussion of how methods marked with MethodImplOptions.InternalCall are actually implemented, where the implementation is, and how the jitter can even substitute some functions directly with a single machine code instruction.
In the post you can see the Sin, Cos, Sqrt, Round functions are eligible to be implemented as a direct machine code instruction. As Hans points out, this can lead to C# floating point code that’s actually faster than the same code in C++ that uses library functions.
So on this case, I managed to escape from StackOverflow intact, and with an increased knowledge of MethodImpl.InternalCall, which is something I had been curious about for over 10 years.
Code and a glass of wine 