Actor Framework Discussions
"Breaking the tree" for stuff like logging
I've always followed the strategy of keeping all of my messages "within the tree" and it's worked well for me. I understand the rationale behind why to do it that way and absolutely don't want to fight the rule, but global logging (for debugging, test activity logs, etc.) has always confused me.
A simple logging functionality would be a regular by-ref Object that gets shared around with whoever needs it, and can write to a database or text file or whatever.
However, if you decide sometime that this needs to be an Actor, then "the rule" is that you can no longer just share the object/reference/whatever with everyone as it starts breaking the tree. Rigidly following the rules means you now have to forward logging messages throughout your system, which feels like a code smell.
What's the best way to handle Actors like this that just need to act as a message sink? Sharing the enqueuer directly is icky and sets a bad precedence. Would wrapping a logging Actor up in another Object be OK, or am I setting myself up for failure since I'm technically introducing another messaging channel that circumvents the tree? If that's bad, why does it matter if it's a shared reference to a file path instead of a shared reference to an Actor's queue if both are hidden from the calling code?
Beginners blindly follow the rules.
Expert know the rules well enough to know when it is ok to break the rules.
You have been around long enough you are no longer a beginner. If it is just a message sink, it is ok to break the rule.
Don't overthink it. Break the rule.
@Taggart wrote:
Beginners blindly follow the rules.
Expert know the rules well enough to know when it is ok to break the rules.
You have been around long enough you are no longer a beginner. If it is just a message sink, it is ok to break the rule.
Don't overthink it. Break the rule.
I appreciate your confidence in me, hah.
All of my instincts told me that it would be fine... but I've thought myself smart enough to break rules before, and have regretted it 🙂
Plus, this topic comes up frequently, so being able to point newcomers to a discussion is helpful.
(I'm currently helping onboard a new dev, and it's been making me rethink the "why" of a lot of stuff that I normally just "do". It's been a good learning exercise for me.)
Have you looked at the message forwarding utility from Zyah Solutions.
I started using that a while ago for my actors and now I don't need to bother about actors forwarding messages to other actors or getting messages up the tree to the correct place.
You only have to declare which messages your actor can send and wants to receive in your prelaunch init.
I think that's a very good solution for getting all your data to a logger.
By the way, it doesn't break the tree. It just takes away all the hassle to do the forwarding yourself.
Best regards,
Stefan
While I feel like in this particular case it is perfectly fine to break the rule, both Avogadro's and Stefan's solutions are also fine solutions.
@drjdpowell wrote:
@StefanLemmens wrote:
By the way, it doesn't break the tree. It just takes away all the hassle to do the forwarding yourself.
I'm not an AF user, but doesn't that break the point of the tree rule?
The messages still follow the tree up and down but an actor can send (or publish/announce) something without even knowing who will listen to it.
So technically the messages still go up and down the tree but indeed the strict tree rule is "abstracted" (I wouldn't call it broken)
In the case you want to send messages from a nested actor to a sibling actor it's just convenient that you don't have to handle those messages in the calling actor for example.
It removes a lot of "just-forwarding" code.
Best regards,
Stefan
@StefanLemmens wrote:
@drjdpowell wrote:
@StefanLemmens wrote:
By the way, it doesn't break the tree. It just takes away all the hassle to do the forwarding yourself.
I'm not an AF user, but doesn't that break the point of the tree rule?
The messages still follow the tree up and down but an actor can send (or publish/announce) something without even knowing who will listen to it.
So technically the messages still go up and down the tree but indeed the strict tree rule is "abstracted" (I wouldn't call it broken)
In the case you want to send messages from a nested actor to a sibling actor it's just convenient that you don't have to handle those messages in the calling actor for example.
It removes a lot of "just-forwarding" code.
Best regards,
Stefan
It does seem like "breaking the tree but with extra steps" since the stuff in the middle doesn't know about it. But of course I haven't tried the toolkit out.
What benefits does it offer vs. sharing the enqueuer directly? (I'm confident there ARE benefits, apologies if this comes off as combative!)
