Hi. In an academic project before sending a regular message (implemented as ! in Akka) I need to check some properties and send some monitoring messages.
Considering limited access to actors I have to some how wrap these functionalities inside Akka library.
My question is how and where to implement a send function similar to !; if its possible.
There is no extension point to hook in custom code in all ! operators. For local actors you can do that in a custom mailbox when the message is enqueued, but in a cluster that mailbox will be on the receiving node.
Could I explain what I am expected to do in more detail so you can help me to build it another way?
what I did was to implement a send function named !! similar to ! in local actor ref and overrode it on other actor classes; (the class was private and I did not have access to the method). I added a priority mailbox that dequeues control messages first (this mailbox is tested and actually works). there is an automata class to which can represent the state of the application(which messages are sent and received). in !! function, Actor checks the status of it’s other sent messages using control messages and scala Futures. when the Actor is definite that sending the new message won’t set the status of automata in an undesired state it sends the message.
Is there a another way to go with this scenario?
Can I share the repo that I forked from Akka with you?
I think he means forking the akka source and building custom packages
I’m not familiar by akka, but it seems you should add your logic int ! function in the LocalActorRef:
override def !(message: Any)(implicit sender: ActorRef = Actor.noSender): Unit =
actorCell.sendMessage(message, sender)
If you are adding a new !! operator you can maybe add that as a Scala extension method to ActorRef?
With what you describe you are essentially dropping the message when certain conditions are met (because there is nothing else that can be done in implementations of ActorRef.! without breaking Akka, in general). May I ask why you need to build it into this particular point? You could also wrap the receiving behavior and discard messages there, which is a lot simpler to implement and much more likely to be correct.
If this is not adequate, would you mind explaining a bit more about what you are really trying to achieve? I’d like to get a picture of the larger context of your research.
Regards,
Roland
Is it possible? Which Actor Class should I extend?
Thanks for your reply. I don’t know how to actually do the wrapping that you suggested. In an insecure system messages passed between actors could be observed by an intruder and he could come up with a conclusion about the overall behavior of the system. In some case we want messages not to be sent in order not to be observed.
If the system is unsecure in a way that messages can be intercepted between actors, then it is implausible to assume that private state in the actors is safe from espionage; in other words, the example seems contrived. If you are talking about securing information when sent over an unsecure medium (like a network transport) then that would make sense; but in that case it is impossible to inspect the target actor’s state in order to decide whether to send the message.
To put it differently: the core communication primitive between Akka actors is very specifically designed to give you very specific guarantees and I have yet to see a valid use-case for modifying it. In all cases, it is much better to build on top of it instead, by wrapping ActorRef in your own type or by wrapping your own actor logic such that Akka is only used as execution engine for your wrapper.
As an illustration of the last point, consider that Akka Typed is implemented in this exact fashion: all the APIs offered by Akka Typed are implemented under the hood by delegating to the untyped akka-actor package.
By wrapping you mean to extend ActorRef classes? If yes specifically which class should I extend?
I understood the concept but I have no idea how to syntactically and technically do that.
No, wrapping means that you create a completely new class that has nothing to do with Akka, and one of the (private) fields of this class holds an ActorRef. That ActorRef is then used to implement whatever methods you want to put on the class, for example for sending messages. That way you completely hide Akka under your own API, which gives you the freedom to do whatever you want.
1 Like
Thanks a lot. I will try that.
So I did a little bit of homework and realized with wrapping ActorRef and hiding Akka I cannot take advantage of all the features. After all, I want to implement a new type of Actor that could be restarted and should adopt all the thread related mechanisms of Akka. So what do you suggest?
It is impossible to answer this question: what are the precise features you cannot take advantage of? What I was proposing is that you build your own complete Actor implementation, using Akka only as the underlying execution engine, i.e. you add a layer on top with your own API and the logic you want to inject when actors interact with one another.
So I have to implement all the other Actor logic too? Including restart methods i.e. preStart() method and so on? I just want to inject a send functionality keeping other functionalities the same.