await myState.GetStateAsync();
It would be error prone if you had to check
.Value before calling .LoadStateAsync()
Has anyone messed around with running Orleans on Tye yet?
@ReubenBond What I found annoying in DARP .NET SDK when I tried it, there was no way of loading multiple states in parallel. Underlying implementation isn't thread safe (and I don't think it needs to be) so you can't run multiple task simultaneously. If similar API would be used for Orleans I think you should add some multi get state feature to it.
Hi, one generic question about polymorphic behavior... assume we have a base shared by grain types, with an interface, like BaseGrain and IBaseGrain... using .GetGrain<IBaseGrain>(id) (some id, e.g. guid) makes the runtime throw an exception telling that multiple grains implements BaseGrain and runtime doesn't know what of the grain types to pick (e.g. instantiate)
(I'm thinking out loud while writing this) :-)
now assume that we already have a grain stored, with a concrete type, e.g. Player that's based on BaseGrain, e.g. class Player : BaseGrain, IPlayer with some id (e.g. guid again)
then one thought would be that using this id again, with .GetGrain<IBaseGrain>(id) would be enough to get the proper grain with runtime... maybe
however, this will not work
and it works with that, e.g. .GetGrain<IBaseGrain>(id, "namespace.Player)
@wanton7 how does that look? It's more of an API/usability issue than a technical one. If the state was injected as ILazyGrainState<T> for example, then at least it's clear by the type. Alternatively, maybe a separate attribute or a parameter to the attribute could make it more clear. That way, at least it's obvious when debugging user code that they haven't loaded the state. I suppose we could also throw if the user tries to access .Value without first having called LoadStateAsync
1 reply
@ReubenBond will to watch the talk
Hi guys, can I take a grain reference, serailize it and then invoke a grain from that deserialized reference? As an example, I have a Player grain, and then I have the following: var player = clusterClient.GetGrain<IPlayer>(id), and do the following playerReference = player.AsReference<IPlayer>()
Following with some serialization (e.g. Json) of the reference
then how do I deserialize into a workable grain reference?
@LeftTwixWand Indexing is not currently supported. What we do is not use Orleans state management currently and we use Entity Framework Core with Orleans. Another option we are currently thinking is that we inject something like IIndexManager for grains that needs indexing and when you change grain state that would effect index you call method from it to update index in database that support indexes. Example if you had CommentGrain you would call UpdateComment(grainId, ...). Then have all grain state in normal Orleans state as JSON blobs but you would have separate tables for grains that need indexing.
just watched the orleans session https://www.youtube.com/watch?v=J9oJTKwASjA&feature=youtu.be&t=13560 from DotNetConf, great session @ReubenBond !
Thanks!
If something like this
GetGrains<IUserGrain>().Where() will works - Orleans'll become to the best serverside solution.
I could use a sanity check. when I use the ISiloBuilder in aspnet core like this:
.UseOrleans(builder => {
builder.UseLocalhostClustering()
.Configure<ClusterOptions>(opts => {
opts.ClusterId = "pine";
opts.ServiceId = "v1";
})
.Configure<EndpointOptions>(opts => {
opts.AdvertisedIPAddress = IPAddress.Loopback;
})
.ConfigureApplicationParts(parts => {
parts.AddApplicationPart(typeof(CustomerGrain).Assembly).WithReferences();
});
});the WithReferences() method doesn't resolve and I get this build error: Program.cs(35,54): error CS1503: Argument 1: cannot convert from 'System.Reflection.Assembly' to 'Orleans.ApplicationParts.IApplicationPart'. I have the Microsoft.Orleans.Server and Microsoft.Orleans.Runtime.Abstractions installed, I thought that would include everything I need, but I think I might be missing something. what am I missing?
From the
Microsoft.Orleans.Core package
May be of interest here due to distributed systems nature: https://blog.zkga.me/announcing-darkforest.
@sayiliromer clients will automatically detect failure and avoid those servers. They will periodically retry previously "failed" servers to account for temporary network issues. There are also hooks on the client to receive an event when the number of connected servers changes