Orleans: Question of 3.0/AspNetCoreCohosting samples

[hotyes]

Hi there, may I ask:

Q1: If this sample (https://github.com/dotnet/orleans/tree/master/Samples/3.0/AspNetCoreCohosting) is recommended to production?

Q2: If I only want to use the actor model without clustering, is it ok just use UseLocalhostClustering?

[KevinCathcart]

Q1: If this sample (/Samples/3.0/AspNetCoreCohosting@master) is recommended to production?

The basic co-hosting approach shown is entirely suitable for production. However, there are a few things to note.

First, normally the development oriented UseLocalhostClustering provider should be swapped out for a better one suitable for a multi-silo cluster that runs on multiple machines.

Second, you would probably want to add at least one storage provider, and possibly a reminder or a streaming provider.

Third, there is also likely more settings you might want on the ASP.Net Core side for a production implementation, like enforced HTTPS.

Q2: If I only want to use the actor model without clustering, is it ok just use UseLocalhostClustering?

If you only want the virtual actor model, and you do not currently need to scale to more than one machine, then using a single silo is just fine. Obviously you lose out on the benefits that clustering provides[0] but not every project actually needs those.

For the single silo case, then I'm pretty sure UseLocalhostClustering should be fine. The parts that normally make it unsuitable for production really don't apply in a single silo case. That is especially true if the only client is co-hosted in the same process, as would be typical with ASP.Net Core co-hosting.

However all that said, using a "proper" membership provider is rather easy, especially if you chose the one that corresponds to your storage provider, so the official recommendation would be to do that.

Footnote:

[hotyes]

hi @KevinCathcart thanks for your information.

Just wondering, if use co-hosting, meaning all silo will also run a http server on their own side which feel weird. that's normal?

[KevinCathcart]

The main use cases for co-hosting is either:

a) you want to add Orleans functionality to an existing http service. By co-hosting
you can avoid needing new services, and can just run Orleans inside your existing web code base.

or

b) You are creating some new service based on Orleans, and want to support a web API for it. Rather than needing to create an extra little web API service that is just a thin wrapper around an Orleans client (a second service you need to deploy, manage etc), you can host the API from directly within the cluster.

If neither is your intended use case, then asp.net co-hosting is probably not the right sample project to base your work on.

[JorgeCandeias]

Just wondering, if use co-hosting, meaning all silo will also run a http server on their own side which feel weird. that's normal?

This is totally normal under the hosted service development model, a popular model in .net microservice development. There is nothing weird about it. Here's an article from the .NET Application Architecture Guidance web site. My team uses the .net generic host all the time and we just tack services on it, including Orleans, Kestrel and others. It works fine and it lets you scale the silos and the API at the same time by just adding more do-it-all nodes.

With Orleans, this model can potentially provide a performance boost, as some grain requests can get resolved locally (in the same node where user api request gets to) and not incur further serialization, but this depends on your own particular design.

[hotyes]

Hi guys, thanks

I am testing now. I am using LocalHostClustering since I only need the virtual actor model without clustering. so far all good only this warning:

[06:30:02 WRN] Watchdog had 1 Health Check Failure(s) out of 6 Health Check Participants.
[06:35:02 WRN] Timer should have fired at 03/23/2020 11:37:10, which is 18:57:51.8970442 ago
[06:35:02 WRN] Watchdog had 1 Health Check Failure(s) out of 6 Health Check Participants.
[06:40:02 WRN] Timer should have fired at 03/23/2020 11:37:10, which is 19:02:51.9540867 ago
[06:40:02 WRN] Watchdog had 1 Health Check Failure(s) out of 6 Health Check Participants.

What I should do to avoid this?

[KevinCathcart]

I think that warning is being caused by a minor bug in 3.1.3, that should be fixed when 3.1.4 or 3.2.0 gets released. See #6410

Basically the health check is checking that a timer is running, but that timer is not supposed to run with certain clustering providers, those that do not support an optional cleanup step. So it gives a false warning. No harm is caused by this, except for useless warnings in the log.

[hotyes]

Thanks @KevinCathcart

[sergeybykov]

@hotyes Can we close this now?

[hotyes]

hi @sergeybykov yes, its good to close, thanks.