Abstract messages without concrete implementations and error 1608

[auspex]

While testing part of project using the actor framework, I started to receive error 1608 from one test and it took me a little while to find the source.

Called from one actor, the child actors worked fine. Called from another actor, they would stop with error 1608. The latter actor implemented the child actors' abstract messages in a different way and I suspected that was the problem at first. I finally realized the source of the emergency stop was neither an error in the child actors nor in the parent actor's implementation of the child actors' abstract messages, but it was instead an error in what the parent actor did next.

This parent actor pools data from the child actors and then passes that on to its own parent (the grandparent) with another abstract message. Because I was testing, there was no grandparent actor, no enqueuer to send to, no concrete implementation of the abstract message. Attempting to pass on the data generated an error which caused the pooling actor to stop and its child actors to stop. This wasn't immediately obvious because the UI on the pooling actor was not receiving its stop message.

One might identify other problems from this description--like a failure to handle errors in the right places--but this did lead me to realize that I might want to protect my actors against being used without concrete implementations of their abstract messages. One easy, though perhaps insufficient, way to do this is to make sure that there is a caller's enqueuer before trying to send anything to it. I've not yet considered what to do if there is a caller's enqueuer but that caller has no implementation of the abstract message.

I couldn't find this particular problem identified in the community, though I wonder if https://decibel.ni.com/content/message/42878 was a related problem. I hope this is helpful to someone else.

[Oli_Wachno]

auspex schrieb:

....

This parent actor pools data from the child actors and then passes that on to its own parent (the grandparent) with another abstract message. Because I was testing, there was no grandparent actor, no enqueuer to send to, no concrete implementation of the abstract message. Attempting to pass on the data generated an error which caused the pooling actor to stop and its child actors to stop. This wasn't immediately obvious because the UI on the pooling actor was not receiving its stop message.

...

I'm a bit confused about the usage of the term Abstract Message.... such a message is a predecessor for concrete messages. IMHO abstract messages are not to be sent: since an abstract message has no own implementation, it'll eventually call Do.vi from message.lvclass resulting in.... nothing, since this method does exactly this

Did I get something wrong?

[auspex]

The provider of the abstract message was trying to send it to an enqueuer that did not exist.

In the Air Cooler demo, the Dual Fan class provides the abstract Update Fan Status Msg which has the method Send Update Fan Status. The "Send" method is provided by the provider of the abstract message, not any concrete implementation, because that's all the provider of the abstract message knows.