Is there a way to fetch some receptionist listings outside of actor. From documentation I see examples where some actor is subscribed to receptionist listing, but can I do it outside of actor facility.
If you have a reference to the ActorSystem, you can call the receptionist method to get an ActorRef for the receptionist.
Related
In some cases, an actor may need to keep an ActorRef for later communication with other actors. I'm wondering if I can put the ActorRef into a persisted event so that I can recover the reference to an Actor later on?
I have question about ActorSelection/Receptionist in new Akka Typed.....
Before Akka Typed I didn't use ActorSelection because I read somewhere that it was not performant so I kept reference to the actor over HashMaps, now I am reading the documentation of the Akka Typed, I see that another mechanism Receptionist exist, so for me the question is, does it also suffers the same problems ActorSelection and I should stick to my old pattern of keeping reference to Actor over HashMap or now the receptionist is the way to go....
My specific scenario, my Actor spawns several Child Actors creates several Child Actors, if the parent Actor passivates or restored over Akka Persistence, it should again find reference to these Child Actors....
So what do you think, would I experience Performance problems if I convert to Receptionist?????
Thx for answers...
ActorSelection will resolve the actor path to an ActorRef each time you use it, this is somewhat costly, if used for a high throughput actor but has the upside that if the actor is stopped, and then later a new actor is started at the same path, the ActorSelection will deliver messages to the new actor, while if you had an ActorRef it specifically points to the actor instance that is no stopped and messages end up in dead letters.
The receptionist is quite different and is more like a registry of actors that you can subscribe to. When the set of ActorRefs registered for a key changes you get an update message with the new set, there is no extra overhead per message sent, you are dealing directly with the ActorRefs of the recipients.
Note that you can use the GroupRouter for delivery to actors registered with the receptionist and to avoid having to implement the subscription part in your actor.
I am trying to implement eventsourcing using Akka persisten actors. The receiver actors are persistent, they persist the message before processing them. I have a round-robin-pool of persistent receiver actors. Now since the persistent id is same for these pool of actors, how to handle recovery? Or i want to understand the correct way of using persistency with pool of actors...
I was thinking to use this propery 'akka.persistence.max-concurrent-recoveries = 1'.
NOTE: i am using java
According to docs:
Note persistenceId must be unique to a given entity in the journal
(database table/keyspace). When replaying messages persisted to the
journal, you query messages with a persistenceId. So, if two different
entities share the same persistenceId, message-replaying behavior is
corrupted.
Seems that you need akka cluster-sharding with unique persistenceId for every entity actor.
Also see:
Can I Read/Write from separate actors with same PersistenceId?
I would like to ask for pattern when it is required to init actor state from database. I have a DAO which return Future[...] and normaly to be non blocking message should be send to actor on future complete. But this case is different. I cannot receive any message from actor mailbox before initialization complete. Is the only way to block actor thread while waiting for database future complete?
The most trivial approach would be to define two receive methods, e.g. initializing and initialized, starting with def receive = initializing. Inside your inizializing context, you could simply send back a message like InitializationNotReady to tell the other actor that he should try it again later. After your actor is initialized, you switch your context with context become initialized to the new state, where you can operate normally.
After all, another good aproach could be to have a look at Akka Persistence. It enables stateful actors to persist their internal state so that it can be recovered when an actor is started, restarted after a JVM crash or by a supervisor, or migrated in a cluster.
In you case, you can restore your state from a database, since their are multiple storage options for Akka persistence. you can find them here. After that recovery, you can receive messages like you're used to it.
Does Akka's EventBus work with remote actors?
As far as I can tell, it doesn't natively support this. Can anyone confirm please?
It looks like it would be possible to code some Actors that provide similar functionality. E.g. start up a remote actor that subscribes to the EventBus on the remote server, and send the messages back to a local actor to republish on the local EventBus. But there is no point writing this, if it is already supported!
Thanks
The EventBus itself is local, meaning that events are not automatically transferred to EventBuses on other systems, but you can subscribe any ActorRef you want, including remote ones. You only need an actor on the node where the events are generated:
case class Subscribe(clazz: Class[_])
system.actorOf(Props(new Actor {
def receive = {
case Subscribe(c) =>
context.system.eventStream.subscribe(sender, c)
}
}), "eventer")
Then you can look that one up from remote hosts and have yourself subscribed.