I'm searching for encapsulation methods like private for class members. I'd like an actor to provide accept some common harmless messages and privileged that could possible mutate state in undesirable way. I can also build proxy actor that would filter messages based on access policy. But both actors would be still available via full path actor ref. How can I made some actor ref private, that can be accessed only by its parent?
Any actor can be addressed by any other actor so long as the path is known by using ActorSelection.
If you want to restrict certain messages, you can do so with things like package-private.
Say you have DangerousActor and you only want actors defined in the same package to be able to send DangerousMessage, but you also have SafeMessage and you're fine with anyone else in the actor system sending that.
package dangerous
object DangerousActor {
private[dangerous] case object DangerousMessage
case object SafeMessage
}
case DangerousActor extends Actor {
import DangerousActor._
def receive = {
case DangerousMessage =>
case SafeMessage =>
}
}
Only actors also defined in the dangerous package will be able to reference DangerousMessage.
Related
In my task parent actor create some child actors and send message to them
def apply(): Behavior[CreateBranch] = {
Behaviors.receive { (context, message) =>
val child1 = context.spawn(Child(), "child1")
val child2 = context.spawn(Child(), "child2")
val child3 = context.spawn(Child(), "child3")
context.children.foreach {
child ! Child.SomeMessage
{
}
}
Child actor defined as:
object Child {
sealed trait SomeMessage
def apply():Behavior[SomeMessage] = {
// some behaviour
{
}
But expression "context.children" does not work: children defined as Iterable[ActorRef[Nothing]] instead of Iterable[ActorRef[Child.SomeMessage]]
In documentation about "context.children" ActorContext.children
"this is not a useful way to lookup children when the purpose is to send messages to them."
And this document suggest alternative way of realisation - but it about of 30 lines of code!
Is there any other alternative way to realise broadcast message send ?
There is no way in general to guarantee the static type of the child actors (and the same is true of the parent actor and the guardian actor (context.system)).
However, if you're absolutely sure that all children will accept the message you can
context.children.foreach { child =>
child.unsafeUpcast[Child.SomeMessage] ! Child.SomeMessage
}
As the name implies, this is unsafe and allows you to send messages without any guarantee that the child will handle them. Since the implementation of an Akka Typed Behavior involves a classic actor which performs message casts, a mismatch between Behavior and ActorRef can cause the actor to immediately fail. unsafeUpcast is (at least from the sender's perspective...) safer than an asInstanceOf cast, as this at least guarantees that you're actually calling ! on an ActorRef.
You asked "Is there any other alternative way to realise broadcast message send ?".
Levi's answer is the most technically correct. But I think the "real" answer is not to use context.children. This complication is caused by the type system trying to protect you from something that is a very legitimate concern. That collection contains ALL children. And there are lots of times I might spawn a child just to monitor a timeout, receive a single message, or some other task that might not understand that message.
If you want to send a specific message to child actors, as was pointed out in Levi's answer, you probably don't really mean "all child actors", you mean "all child actors who understand this message". And although there are some other ways you could do this, I always find it easiest just to maintain your own collection of ActorRefs for an actor of a particular type. If I have "worker actors" I maintain my own sequence and then the message types just work automagically.
My experience is that you should really only use context.children for system-type operations. But anything else, I maintain my own collection. That way if I create a new type of child actor at a later date, I don't break any assumptions I'm making about the type of child actors and what messages they can receive.
I want to make a library that is going to be used and configurable by other people, using akka actors.
I want to make a Repository actor to which a type of storage will be injected by the library user like "MemoryDatabase" or "FileDatabase" or anything that extends a defined class or actor (see question 2).
1) What is the best way for a user to specify options (including his own created ones)?
2) Should "MemoryDatabase" be an actor child of repository, or just a normal class as a field/property of the Repository actor in this case?
Thanks!
-Jojolepro
Edit:
I want to make an actor that looks like
class Repository extends Actor{
val repoType:DataStorageType = ...
def receive:Receive={}
}
What I want to know the best way for a end user of such library to specify the repoType field, considering that Repository is already in a predefined actor hierarchy.
It depends on if you want the user to put in a concrete instance or merely a type. Ignoring any kind of DI system you could use, I would merely pass the concrete instance to the actor's constructor via props when the actor is started but then that would depend on the concrete instance being thread safe because not necessarily only that actor would be managing it. If you want the actor to own the repository, have the user pass the factory instance or type to the props and thus the constructor.
I am fairly new with Akka framework and Concurrency concepts. And from Akka docs, I understood that only one message in the Actor mailbox would be processed at a time. So single thread would be processing Actor's state at a time. And my doubt is that, so declaring an Actor state/data variable as mutable - 'Var'(Only when 'Val' doesn't fit), will not cause inconsistent Actor states in the case of Concurrency.
I am using Scala for development. In the following Master actor, details of workers is stored in a mutable variable 'workers'. Will it be a problem with concurrency?
class Master extends PersistentActor with ActorLogging {
...
private var workers = Map[String, WorkerState]()
...
}
I think what you are doing is fine. As you said, one of the fundamental guarantees of Akka actors is that a single actor will be handling one message at a time, so there will not be inconsistent Actor states.
Akka actors conceptually each have their own light-weight thread,
which is completely shielded from the rest of the system. This means
that instead of having to synchronize access using locks you can just
write your actor code without worrying about concurrency at all.
http://doc.akka.io/docs/akka/snapshot/general/actors.html
Also, it is a good thing that you're using a var instead of a val with a mutable map :)
Another way to consider coding situations like these is to alter the actor's "state" after each message handled. Eg.:
class Master extends PersistentActor with ActorLogging {
type MyStateType = ... // eg. Map[String, WorkerState], or an immutable case class - of course, feel free to just inline the type...
def receive = handle(initState) // eg. just inline a call to Map.empty
def handle(state: MyStateType): Actor.Receive = LoggingReceive {
case MyMessageType(data) =>
... // processing data - build new state
become(handle(newState))
case ... // any other message types to be handled, etc.
}
... // rest of class implementation
}
While it is true that there is still mutable state happening here (in this case, it is the state of the actor as a whole - it becomes effectively a "non-finite state machine"), it feels better contained/hidden (to me, at least), and the "state" (or "workers") available to the actor for any given message is treated as entirely immutable.
I just start trying myself out with Scala. I grow confident enough to start refactoring an ongoing multi-threaded application that i have been working on for about a year and half.
However something that somehow bother and i can't somehow figure it out, is how to expose the interface/contract/protocole of an Actor? In the OO mode, i have my public interface with synchronized method if necessary, and i know what i can do with that object. Now that i'm going to use actor, it seems that all of that won't be available anymore.
More specifically, I a KbService in my app with a set of method to work with that Kb. I want to make it an actor on its own. For that i need to make all the method private or protected given that now they will be only called by my received method. Hence the to expose the set of available behavior.
Is there some best practice for that ?
To tackle this issue I generally expose the set of messages that an Actor can receive via a "protocol" object.
class TestActor extends Actor {
def receive = {
case Action1 => ???
case Action2 => ???
}
}
object TestActorProtocol {
case object Action1
case object Action2
}
So when you want to communicate with TestActor you must send it a message from its protocol object.
import example.TestActorProtocol._
testActorRef ! TestActorProtocol.Action1
It can become heavy sometimes, but at least there is some kind of contract exposed.
Hope it helps
My app gets a new instance of Something via an API call on a stateless controller. After I do my mission critical stuff (like saving it to my Postgres database and committing the transaction) I would now like to do a bunch of fire-and-forget operations.
In my controller I send the model instance to the post-processor:
import _root_.com.eaio.uuid.UUID
import akka.actor.Props
// ... skip a bunch of code
play.api.libs.concurrent.Akka.system.actorOf(
Props[MySomethingPostprocessorActor],
name = "somethingActor"+new UUID().toString()
) ! something
The MySomethingPostprocessorActor actor looks like this:
class MySomethingPostprocessorActor extends Actor with ActorLogging {
def receive = {
case Something(thing, alpha, beta) => try {
play.api.libs.concurrent.Akka.system.actorOf(
Props[MongoActor],
name = "mongoActor"+new UUID().toString()
) ! Something(thing, alpha, beta)
play.api.libs.concurrent.Akka.system.actorOf(
Props[PubsubActor],
name = "pubsubActor"+new UUID().toString()
) ! Something(thing, alpha, beta)
// ... and so forth
} catch {
case e => {
log.error("MySomethingPostprocessorActor error=[{}]", e)
}
}
}
}
So, here's what I'm not sure about:
I know Actor factories are discouraged as per the warning on this page. My remedy for this is to name each actor instance with a unique string provided by UUID, to get around the your-actor-is-not-unique errors:
play.core.ActionInvoker$$anonfun$receive$1$$anon$1:
Execution exception [[InvalidActorNameException:
actor name somethingActor is not unique!]]
Is there a better way to do the above, i.e. instead of giving everything a unique name? All examples in the Akka docs I encountered give actors a static name, which is a bit misleading.
(any other comments are welcome too, e.g. the if the bundling pattern I use is frowned upon, etc)
As far as I'm aware the name paramater is optional.
This may or may not be the case with Akka + Play (haven't checked). When working with standalone actor systems though, you usually only name an actor when you need that reference for later.
From the sounds of it you're tossing out these instances after using them, so you could probably skip the naming step.
Better yet, you could probably save the overhead of creating each actor instance by just wrapping your operations in Futures and using callbacks if need be: http://doc.akka.io/docs/akka/2.0.3/scala/futures.html