doing that with
ContinueWith and PipeTo can be cumbersome
if your error handling is pretty simple
i.e. pass / fail error handling
then you're better off with a continuation and pipe to
use the async method
just don't await it
pipe the results to yourself instead
I got it
explains that in more detail
although my comments about await in that blog post are outdated
as I mentioned earlier
I'm not sure if that's feasible or even possible
Yeah... it just seems like there must be a better way. For example, if you want to lookup who owns an object, then do something if that owner has
IsAdmin = true setting. Currently you might lookup by ID to fetch the user record and, based on that, find the pref, then perform the original action. This might vary depending on if you're looking up the owner vs. the creator, for instance. So there's a bunch of what feels like unnecessary keyboard mashing in order to pass along enough information to be able to process the result based on the state of the original request.
If not, what is the right way to do it? Make the children ask the parent for the init info?
most of the changes, it introduces, are available right now in form of optional settings or plugins
Hi, I'm trying to figure out the best way to implement this architecture:
- in an ASP.NET application a controller is receiving requests: each request must be dispatched to an entity represented by an actor.
- there are many instances of the same actor: each request must be dispatched to the right instance of the actor (base on a parameter witch is available within the controller action)
- there should be a Coordinator actor that is responsible for the life time of all instance actors: if the instance actor does not exist when the request comes in, the coordinator must create the actor. Base on some event the coordinator actor must also kill instances not needed anymore.
The obvious choice seems to have one coordinator actor managing the list of instances actor (through a dictionary of instances). The problem with this solution is that it doesn't scale: the coordinator actor is the bottleneck.
What is the best approach?
It would be great even if the actor instances may be spread on remote machine as well.
I think that at the end the problem can be state as follow: what is the best way to manage the life time of many actors of the same type that can potentially be spread on many remote machine.
Sounds to me you want to use an consistent hashing group http://getakka.net/docs/working-with-actors/Routers#consistenthashing.
When it comes to distributing this across machines i think the cluster sharding feature is want to you want to look at cluster sharding: http://doc.akka.io/docs/akka/current/scala/cluster-sharding.html http://getakka.net/docs/clustering/cluster-sharding
since that came out sooner than expected
@easysoft2k15's questions look like ddd-related ones to me. I'm exploring the possibilities to implement a ddd-cqrs system with akka.net too. Regarding @Danthar's answer with a consistenhashgroup router, can we add more routees at runtime after the creation of the router? In DDD terms it would be: Lets say I have an Entity-Actor Order with an ID, let's say I have 100 of them. This entity-actor handles the CancelOrder command, which is delivered to it via the consistenthash group router, which hashes on the order id. Now we receive a CreateOrder command, with an empty/special ID, so it goes to a special actor which creates a new order entity actor. Now it needs to add the newly created entity to the router, so all subsequent messages directed to /orders/<newly-created-id> go to the new entity actor. How can this be done?
Or even part of 1.5?
@llehn I not sure (I'm not an expert in Akka.NET) but I don't think the system is design to support the solution You suggested. More likely You need an intermediate layer of actors (the router's actors) that manage the Order Actor and send messages to them. In this way the Order Actor make the heavy computation and the Router actors just dispatch messages to the Orders actor in order to avoid the dispatching mechanism being a bottleneck. This is the approach I'm taking right now. Not sure if is the best way to do it though.
and not have to launch the region there too