Aaronontheweb on dev
Backport of #5965 - pass Akka.C… (compare)
Aaronontheweb on dev
Update RELEASE_NOTES.md for 1.4… (compare)
OrderActors and when they die for whatever reason it starts them back up. You may want to read up on the PreStart, PreRestart and PostRestart events that affect that behavior as well.
I'm curious to know what indexing patterns people are using for persistent, remembered, sharded entities, when you need to lookup/address them by something other than the entity ID. Since shards can migrate between nodes, there's always a chance that a shard is currently "offline", so broadcasting/aggregating cant' always be consistent (i.e. while a shard is starting up on a node and loading all entities, those entities won't respond to the broadcast). Consider you have an entity called Contact, with it's ContactID, and you want to find all contacts with a specific phone number. You could of course map the index in a SQL table or something, and do the lookup there. But I'd like to avoid a database roundtrip if possible. Currently I'm using a secondary sharded entity whose entity ID is the "indexed" field, that does nothing other than rewrap the message with the now-known actual EntityID and forward it to its counterpart. It works well, but if you index 4-5 fields, for 100K entities, then you suddenly have 500K-600K entities that a cluster needs to fetch from the event journal on startup (instead of just the 100K), which slows down the startup significantly (lots of DB roundtrips). I've experimented with a cluster singleton that keeps track of indexes, and whenever entities are recovered/altered, they notify the singleton. It works great when the cluster is up and running, and it's fast, but when booting up, lookups return false negatives because the shard hasn't loaded yet and the entities haven't registered. So, I'm curious to know what solutions other people have found for this type of scenario. Are all the cool kids using doing this outside of Akka with SQL tables or similar?
I also considered using singleton with the broadcast/aggregate pattern against the entities, and hook into the cluster node and sharding lifecycle messages to keep track of when "partitions" are online or offline, and buffer broadcasting whenever one of the shards is offline, but that hits pretty hard against "availability" metric.
Does Akka guarantee that this code will process one message at a time?
Journal .EventsByPersistenceId(inventoryName, ++inventoryOffset, long.MaxValue) .RunForeach(HandleCharactersEvent, Materializer); Journal .EventsByPersistenceId(descriptorItemsName, ++descriptorOffset, long.MaxValue) .RunForeach(HandleCharacterDescriptionEvent, Materializer);
Hey guys, I am having trouble using the ActorSelection method. I have just modified the helloakka.cs in the examples to test out some of the funcitonality of the akka system and was looking that the ActorSelection method. I am running into an error when running the code:
[INFO][4/7/2018 3:21:14 PM][Thread 0003][akka://MySystem/deadLetters] Message Greet from akka://MySystem/deadLetters to akka://MySystem/deadLetters was not delivered. 1 dead letters encountered.
I think it is because of how I maybe writing the path for the actor.
var system = ActorSystem.Create("MySystem"); var greeter = system.ActorOf<GreetingActor>("greeter"); var greater = system.ActorOf<ActorGreeting>("greater"); // send a message to the actor greeter.Tell(new Greet("World")); greeter.Tell(new Greet("Nick")); //greater.Tell(new Freak("Fish")); system.ActorSelection("akka://system/user/*er").Tell(new Greet("I am greeter"));