Microsoft Orleans – Advanced functionality – part 2

Note: this is post is part of a serie about Microsoft Orleans and the Actor model

Reactive caching

Using “reactive caching” and “reactive replication” patterns removes the need for external cache replication and most importantly, removes caching invalidation problems – they’re no longer a thing you have to spend hours in meetups discussing.

Reactive Caching is a general way to bring frequently updated data items or snapshots – not events – closer to the consumers that need them, and not to those that don’t, to maximize lookup speed.

It is also useful when the incoming events from the server to the client are so many that individual clients will lag in relative terms (slow/fast consumer problem) yet individual consumers don’t care about the events at all – they only care about what those events build up to, as in, to paint some data grid or chart.

The client just wants to always get the latest snapshot of some data view as fast as their own network allows.

Clients with different speed (slow/fast consumer problem)
All the clients are getting all the events
Clients getting the snapshot when they can

So what’s the benefit of using Reactive Caching compared to something like SignalR?

The benefits will depend on the use case. There may be some or none. SignalR works fine for common event-based workloads. Reactive Caching is a general way to bring frequently updated data items or snapshots – not events – closer to the consumers that need them, and not to those that don’t, to maximize lookup speed. It is also useful when the incoming events from the server to the client are so many that individual clients will lag in relative terms (slow/fast consumer problem) yet individual consumers don’t care about the events at all – they only care about what those events build up to, as in, to paint some data grid or chart. Relative lag is a common problem in some industry. It is by no means a silver bullet and requires some specific conditions to work (such as an actor-like system) but when you have them in place, it works fine.
Also, as reactive caching is just a pattern, you can even do it over SignalR if the use case (and the lag) justifies it. What about using long-poll HTTP requests?

Browsers will impose a connection limit per domain. For Chrome this is 6 connections per domain. Each active long-poll counts towards this limit. If the application is issuing a lot of long-polls at the same time, then you will start seeing things not updating when they should. That’s not something you want your users to notice. Why do it then? Once you’re serious, implement high-level SignalR or low-level WebSockets, or some other multiplexing-capable communication technology. Persistent connections are one of the basic building blocks of real-time applications.

More in-depth explanation can be found at this (great) resources:

Co-hosting cluster & http client

This can be achieved using the Hosted client, enabled by default from Orleans 2.3. The documentation is coming, take a look at the github issue here. In the meantime take a look to this stackoverflow thread. That means a silo and a http api may be the same process, so no serialization would be done in that case.

So if you use the hosted client (introduced in 2.1.0, enabled by default in 2.3.0) then the hops would be
http client ⇒ load balancer ⇒ http api ⇒ target silo
(target silo & http api may be same process, so no serialization would be done in that case either)
You can also take a look to another more specific article: Microsoft Orleans – Direct client functionality (with working example)

Calling an external API

Calling an external API from an Orleans grain is fine. If the call can be cached then a stateless worker or a purpose-built response cache can be used as well. Make sure that it’s not blocking and that it’s using HttpClient correctly: make sure to have a single instance of the HttpClient (not an Orleans-related thing). We can view external tasks/threads, external services, etc. as external resources with side effects outside of the actor. Actors can call them and they can call actors, but that doesn’t make these external resources part of the actor.

Orleans Dashboard

The Orleans Dashboard is an indipendent project (in the OrleansContrib repo) that allow to monitor your Orleans silo. It’s very easy to install and to configure, it supports authentication, REST Apis, and it can be fully customizable (frontend written in React).

2 Comments

Add a Comment

Your email address will not be published. Required fields are marked *