search

dotnet / orleans

Cloud Native application framework for .NET
https://docs.microsoft.com/dotnet/orleans
MIT License
10.1k stars 2.04k forks source link

Remove GrainService and provide a better alternative #7103

Open ReubenBond opened 3 years ago

ReubenBond commented 3 years ago

GrainServices are cumbersome and undocumented. They derive from SystemTarget, which is meant only for internal services and was not meant to be publicly exposed. Hence, I think we should remove them.

A preferable alternative would be to have regular grains which have fixed, per-silo placement. Such grains can still include consistent hash rings and a similar kind of "grain service client" which maps the caller's grain id to that hash ring to find the correct grain service can also be implemented.

buzzers commented 3 years ago

I think we should provide a way to specify a node to call. Used to handle process-level services. For example, update the configuration (of course, this can be achieved in other more suitable ways, this is just an example).

ReubenBond commented 3 years ago

Hi @buzzers, I agree. That can be accomplished using custom placement today, but I believe we should include a custom placement provider to do this within Orleans itself.

ghost commented 2 years ago

We are marking this issue as stale due to the lack of activity in the past six months. If there is no further activity within two weeks, this issue will be closed. You can always create a new issue based on the guidelines provided in our pinned announcement.

ghost commented 1 year ago

We've moved this issue to the Backlog. This means that it is not going to be worked on for the coming release. We review items in the backlog at the end of each milestone/release and depending on the team's priority we may reconsider this issue for the following milestone.

gufigueiredo commented 1 year ago

@ReubenBond This issue is still valid? I'm wondering if there is a better way to fetch data (like a Repository) from grains. Is GrainServices still the correct approach?

ReubenBond commented 1 year ago

This issue is still valid - I still want an alternative to GrainServices. For fetching data for grains, I would personally register & inject a regular singleton service like you typically would, rather than use a grain service.

buzzers commented 1 year ago

I was wondering if we could take a legacy actor model like akka and build virtual actors based on it. In addition, I wonder if it is possible to specify that some nodes do not enable grain directory. This is used to reduce the number of actor reactivations when a node restarts.

ReubenBond commented 1 year ago

In addition, I wonder if it is possible to specify that some nodes do not enable grain directory.

I have an idea for this, but it's not related to grain services necessarily. It's not possible today because of how the current in-cluster grain directory works, however.

buzzers commented 1 year ago

In addition, I wonder if it is possible to specify that some nodes do not enable grain directory.

I have an idea for this, but it's not related to grain services necessarily. It's not possible today because of how the current in-cluster grain directory works, however.

It would be nice to have this, it saves me from having to use the redis directory. This is important for some scenarios where actor reactivation needs to be minimized (like online games).

jonathansant commented 11 months ago

Would the "fixed, per-silo placement" grain be long-lived like a grain service? Would you be able to have PeriodicTimers that can live as long as the silo lives?

ReubenBond commented 11 months ago

Yes, using Grains with fixed placement is better. Codifying this pattern would be useful, similar to the existing grain services pattern.

bxjg1987 commented 8 months ago

Has there been any progress on this feature? It is difficult to understand the official documentation on grain service.