Aaronontheweb on dev
Provide static GetRoutees.Insta… (compare)
Actor, which makes it easier to know what messages are generally being sent over the wire vs in process.
I have an aggregator that accepts messages from a remote actor service. I built it because sending all of the data at once was just too large of a message. However, now that it's getting a few thousand messages I'm seeing errors like this.
Akka.Remote.Transport.AkkaProtocolException: Error while decoding incoming Akka PDU of length 28564 ---> Akka.Remote.Transport.PduCodecException: Decoding PDU failed
DotNetty.Codecs.TooLongFrameException: Adjusted frame length exceeds 128000: 128061958 - discarded
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);