dotnet/orleans

Orleans - Distributed Actor Model

Veikko Eeva

@veikkoeeva

I might add, as having build such on nation scale for a state, it's not that simple, but gives very good taste and maybe on how to build it on Orleans. :)

Maybe what I've been written should be just forgotten and take that SSIMeetup example on IoT and imagine Orleans used there. :)

Gabriel Freire

@gabrielfreire

question: i used to suffer a lot when working with RabbitMQ. i used to interact with databases on my consumers and frequently hit concurrency problems, maybe it is my lack of knowledge on implementing better concurrency in the database, but having the data access happen inside a grain saved my life, never had those problems again.

the question is, i'm not very knowledgeable on concurrent database access so i just use Grains in front of it, is this a valid use case or should i stop and learn database concurrency?

True Goodwill

@truegoodwill

https://github.com/dotnet/orleans/tree/main/samples#readme
We overhauled the samples & added a top-level description page for them

This is tremendous @ReubenBond, thank you very much

True Goodwill

@truegoodwill

And just in time for me to investigate using SignalR in an app co-hosted. I saw an example in the GPSTracker sample: https://github.com/dotnet/orleans/tree/main/samples/GPSTracker

Frankly, this looks a bit "preview" to me ... intuitively I expect that using SignalR in a cohosted webapi/orleans cluster should be really simple. All the extra ceremony in the sample project ... it looks like that's necessary because there is no SignalR backplane used in that project ...

I'll take a few minutes now to write some code demonstrating what I would have intuitively expected ... '

Reuben Bond

@ReubenBond

Having an proper backplane for SignalR would be nice

True Goodwill

@truegoodwill

var host = Host.CreateDefaultBuilder(args)
  .UseOrleans((ctx, siloBuilder) => { })
  .ConfigureWebHostDefaults(webBuilder => { })
  // Make signalR available to both the webapi and the orleans.
  .UseSignalR(signalRBuilder =>
  {
    signalRBuilder.UseSomeKindOfBackPlane();
  });

class myGrain : Grain
{
  // automatically injected hubcontext for sending messages directly on the hub
  // to ALL clients no matter which silo instance they are connected to.
  public myGrain(IHubContext<SomeHub> hub)
  {
  }
}

@ReubenBond, redis is an awesome backplane for signalR. Using it is no problem for people deploying with k8 or dockercompose

I'm just not sure how to wire it in.

Reuben Bond

@ReubenBond

How to wire it in to SignalR?

True Goodwill

@truegoodwill

o sorry for being ambiguous, I'm unsure how to configure and inject SignalR so that it can be used as demonstrated in the code above.

I know there are Orleans.SignalR.xxx packages available on OrleansContrib ... I'm just not sure how to use them, and I'm unsure if it's better to use Orleans itself as a backplane, or stick with an external service like redis.

Reuben Bond

@ReubenBond

@galvesribeiro may be able to elaborate on that

Gutemberg Ribeiro

@galvesribeiro

hey

True Goodwill

@truegoodwill

Looks like I'm asking two questions here ...
1) What's the best backplane in this situation (redis is pretty standard and well-used in other situations)
2) How to inject/configure signalR so the hubcontext is available in both the web app and in orleans.

Gutemberg Ribeiro

@galvesribeiro

I had a couple of companies that I remember using Orleans as backplane with that packet. It works just fine

True Goodwill

@truegoodwill

(I'd be happy to add a sample app by way of thanks for the help) ... dockercompose / cohost / signalR / backplane

Gutemberg Ribeiro

@galvesribeiro

in fact, one project I’m starting now will use it

the Orleans backplane allow you to (1) cohost SignalR with the siloes, (2) be a backplane without requiring and external one and (3) allow grains to send messages directly to clients or groups in a simple way (just inject a context interface and send it)

are you have any difficulties with that package, @truegoodwill ?

True Goodwill

@truegoodwill

I've not tried a package yet ... which is the "one" to use?

Gutemberg Ribeiro

@galvesribeiro

SignalR.Orleans

I actually never knew that other one

True Goodwill

@truegoodwill

@galvesribeiro , thank you very much for hopping in by the way.

Gutemberg Ribeiro

@galvesribeiro

but seems quite outdated

:+1:

True Goodwill

@truegoodwill

ok, i'll look at whatever documenation I can find there first, and get back with follow up questions. Thank you so much

Gutemberg Ribeiro

@galvesribeiro

sure

btw, nothing prevents you from use a regular backplane like Redis and cohost in Orleans. I just use it because it is more convenient

True Goodwill

@truegoodwill

ok cool, I've read the Readme on SignalR.Orleans (I noticed you're one of the contributors)

It shows how to add signalR to the silobuilder ... but it does not show how to also add it to the webapi

I think that was the documentation I read a while back that actually started this line of questioning :)

Also, I think my doubt about using SignalR.Orleans as the backplane came from not understanding how it uses the storage. I'm currently using MongoDb for grain state storage ... I have a gut feeling so far that making the signalR backplane use mongodb might just be really slow compared to having a direct redis backplane.

The readme in that package shows how to setup a hub so that grains can write to it ... it does not show how a browser might connect to it to receive data, i imagine the webapi needs to be configured ... and how to configure it so that it uses the same signalr instance as the grains.

True Goodwill

@truegoodwill

o hang on, there's a bit more there ... I just wasn't seeing it, because it was under the heading "client" rather than "configuring the web api"

sorry, I'll take a bit of time now trying it out before coming up with more questions.

Gutemberg Ribeiro

@galvesribeiro

hehehe

it is “magic” :)

the storage is only use to keep the list of groups and the subscriptions

unlike Redis, the messages doesnt go there

the storage is only for know which clients are where

and they are only used for recovering in case a silo die

that same state is kept in memory all the time, so it is faster than Redis since you don’t even need the network call to Redis. Its all in memory and/or direct calls

you don’t even need a persistent storage actually. If you don’t care about maintain the user list and groups in case the whole cluster dies, just use the in-memory storage, it is fine

it is barely used

The readme in that package shows how to setup a hub so that grains can write to it ... it does not show how a browser might connect to it to receive data, i imagine the webapi needs to be configured

Your browser would use a regular SignalR client. It works exactly same way as the other backplanes. A backplane is an infrastructure component at the server side. It has nothing todo with the client.

Where communities thrive

People

Repo info

Activity