These are chat archives for akkadotnet/akka.net

10th
Aug 2016
Corneliu
@corneliutusnea
Aug 10 2016 03:59
Is there a way to broadcast a message to all actors part of a SmallestMailboxPool? It's an init message that I want to reach all children
If not, what is the right way to do it? Make the children ask the parent for the init info?
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 06:18
@corneliutusnea have you tried to send routerRef.Tell(new Broadcast(initMessage))?
hisabir
@hisabir
Aug 10 2016 06:34
Hi, When to expect Akka.Net 1.5 release?
Corneliu
@corneliutusnea
Aug 10 2016 06:41
@hisabir no, I haven't tried that but that's looks like a good way to do it. For now I did it as a PreStart Context.Parent.Tell(new PleaseInitMe()) kind of message that the parent replies with the correct init
hisabir
@hisabir
Aug 10 2016 10:44
release 1.5...
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 10:50
@hisabir the exact date is not yet known
most of the changes, it introduces, are available right now in form of optional settings or plugins
Alessandro Rizzotto
@easysoft2k15
Aug 10 2016 13:15
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.
Arjen Smits
@Danthar
Aug 10 2016 13:23
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
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 13:44
@easysoft2k15 sounds like the case for akka-cluster-sharding
Alessandro Rizzotto
@easysoft2k15
Aug 10 2016 14:16
@Horusiath , @Danthar Thank You. I was thinking about consistent hashing as well. Regarding cluster-sharding I don't have experience right now. I'll take a look
Aaron Stannard
@Aaronontheweb
Aug 10 2016 16:02
@hisabir .NET Core kind of threw a wrench into our release schedule
since that came out sooner than expected
Lev Lehn
@llehn
Aug 10 2016 17:37
@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?
David Rivera
@mithril52
Aug 10 2016 18:00
@Aaronontheweb Speaking of .NET Core and Akka.NET, doers that mean that a .NET Core version of Akka is in the near future? Before 1.5?
Or even part of 1.5?
Alessandro Rizzotto
@easysoft2k15
Aug 10 2016 18:57
@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.
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 19:00
@easysoft2k15 @llehn Akka.Cluster.Sharding is plugin designed to work on actors as aggregate roots, created on demand, migrated, routed and rebalanced across cluster nodes.
Alessandro Rizzotto
@easysoft2k15
Aug 10 2016 19:02
@Horusiath I'll dig deeper in the sharding cluster doc. At the moment (keeping everything on a single machine) I'm adopting the solution I explained above.
Chris Martin
@trbngr
Aug 10 2016 19:03
I'm trying to use Cluster.Sharding with lighthouse but my shards aren't being resolved. Please tell me I can use Lighthouse as just a dumb seed.
and not have to launch the region there too
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 19:04
@trbngr you may need to specify roles for sharding nodes (I'm not 100% sure if it's necessary) and use them in sharding config
Chris Martin
@trbngr
Aug 10 2016 19:04
ok. I'll give it a shot
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 19:05
because cluster sharding may assume, that lighthouse will also host shards
Chris Martin
@trbngr
Aug 10 2016 19:07
            cluster {
              sharding {
                role = "projections"
              }
              #will inject this node as a self-seed node at run-time
              seed-nodes = [
                "akka.tcp://eventdayprojections@168.62.228.228:4053",
                "akka.tcp://eventdayprojections@23.96.183.175:4053"
              ]
              roles = [projections]
            }
          }
look right?
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 19:08
yes
Chris Martin
@trbngr
Aug 10 2016 19:08
still not happening :(
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 19:09
any errors?
Chris Martin
@trbngr
Aug 10 2016 19:10
Trying to register to coordinator at [], but no acknowledgement. Total [1] buffered messages.
oh! I don't have any journal setup
sorry. I've been in Scala-land for the last few months. Trying to get my head back here for a bit ;)
hmm. defaults to inmem, right?
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 19:12
yes, it won't work right between processes
Chris Martin
@trbngr
Aug 10 2016 19:12
right right
what can I use without setting anything up?
leveldb?
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 19:13
sqlite (if all akka processes will point to the same file)
Chris Martin
@trbngr
Aug 10 2016 19:13
hmm. so far this is only one instance. It should work.
wire serializer is also advised (I know, that existing json-based may have some problems with some of the cluster sharding message)
Chris Martin
@trbngr
Aug 10 2016 19:19
Oh yes. I remember that
Chris Martin
@trbngr
Aug 10 2016 19:28
hmm. the db isn't being created. Seems like the persistence module isn't initializing at all
updated gist if you have time to look
wondering if having my seeds over the internet is the problem at this point?
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 19:35
if db is not created, you should have some error messages
could you put logs on the gist?
Chris Martin
@trbngr
Aug 10 2016 19:45
I got it working after starting lighthouse locally.
Big question here is what happens when a node goes down? Do the shards get recreated on another node?
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 19:47
yes - basically shards can be handed over to another node, or rebalanced when the difference in number of shards between nodes goes over some specified threshold
Chris Martin
@trbngr
Aug 10 2016 19:50
seems to hold true ;)
but only if auto-down is set. Well.. I can't tell for sure. Too many logs to see if my messages are received.
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 19:56
I know, that @Aaronontheweb often says to be careful with auto-down, but to be honest - unless you'll specify your own logic for downing nodes, I think it's a reasonable to use it (at least for clusters, which fit into single datacenter).
Chris Martin
@trbngr
Aug 10 2016 19:58
I think that's reasonable too. It's always in the back of my mind though. The Akka guys warn against that hard.
I suppose it's not a huge deal with a small system either
Bartosz Sypytkowski
@Horusiath
Aug 10 2016 19:59
in akka on the jvm you can use split-brain resolver strategies, we don't have them on .net side yet
Chris Martin
@trbngr
Aug 10 2016 20:00
ok. thanks for your help, man. Ima go code now
Aaron Stannard
@Aaronontheweb
Aug 10 2016 20:39
where auto-down kicks you in the nuts is when the unexpected happens
if there's a hardware failure inside azure that knocks out the network for a minute or two
then you have to take your service offline and do a full reboot if every node has downed every other node
it's a remote possibility though
and most businesses that couldn't tolerate that issue
wouldn't tolerate that type of outage in the first place
and would have some sort of data-center level failover
it'll be useful once we have downing providers implemented
makes the strategy for doing automatic downing pluggable
Chris Ochs
@gamemachine
Aug 10 2016 23:43
wanted to confirm behavior on singleton actor. That it's being unreachable that triggers moving it, it doesn't have to be flagged as down before it moves
Chris Ochs
@gamemachine
Aug 10 2016 23:50
The behavior I want in the cluster is that it just degrades as nodes become unreachable. Singleton is always available (minus downtime while being unreachable until started on another node). auto-down disabled. App is a multiplayer game so small number of mostly vertically scaled boxes. Singleton is for a global registry of active games/online players
Aaron Stannard
@Aaronontheweb
Aug 10 2016 23:53
taking a look at the source real quick
to confirm how it works
since I don't know the answer myself
Chris Ochs
@gamemachine
Aug 10 2016 23:54
Or, since we already need a routing system for routing players to nodes for games, I was thinking just not using cluster at all. Have the web app track nodes using our own internal logic, avoid cluster issues completely
looks like the node has to be Removed in order for the handoff to occur
so it becoming unreachable may not do the trick
to cause a handoff
not unreachable events
man, this would be a great use case for Akka.DData
which isn't finished yet
as long as you could tolerate the eventual consistency