Can anything make an Actor ignore a Stop message?

[testingHotAir]

I have one actor in particular that appears to not receive the Stop message sent by its caller, but only when it's not the only Actor in the system AND the application is running on one particular work station.  Frustrating.  Before I get you all involved in a goose chase on the specifics, is there anything the community can think of that would prevent an Actor from executing the Stop Core when a Stop message is sent on its message enqueuer?  I have verified that the queue refnum is valid and that the Send Stop Message vi does not return an error.  The problem actor is otherwise functioning normally ie: starting up normally and processing all other messages correctly without errors.

[justACS · Accepted solution]

One possibility comes to mind.  Does the acto in question have a method that takes a significant amount of time to process?  If so, could that actor be receiving that particular message faster than it can process it?  You could simply have a very long queue of messages to chew through before the actor sees the stop.

You can test for this by sending that actor an emergency stop.  E-stops use the reserved critical queue, and should trump any waiting messages.  If your actor stops in that case, then you're probably stacking messages, and you need to adjust accordingly.

[MattP]

If there is only a direct stop message from actor A to actor B, then niACS's solution is the only one that immediately jumps to mind. 

If the messaging is a little more complex (A->B, B then stops nested actor C), then many more possibilities open up, most common I've seen amongst these is trying to do something in the stop core of B that self-enqueues a message back to B to handle cleanup duties (such as stopping C) - this will never run, since the stop message is the last message B will process.  Thus, C will never be sent a stop message. 

[testingHotAir]

I thought it might have a lot of messages to handle as I've encountered that before, but when all other actors have shut down and I can verify that no new messages are being processed, it still doesn't execute the Stop Core.  I've let it run like that over lunch and it still doesn't get to the stop message.  This actor doesn't have any nested actors under it.  The longest possible message in terms of processing is one that reads three datasockets.  This message gets sent every 250 ms, but is really just polling for events.  I could move this task into a nested actor that runs independently to see if that's the issue.

[maxwellb]

You need to be creative with your debugging here. Breakpoints, launch actor cores with front panels shown, temporarily set some of your VI's non-reentrant, insert a special VI somewhere. You will figure out what is going on if you follow the execution path.

[testingHotAir]

Disabling the part of the message that polled the datasockets brought stop behavior back into line.  Seems there were a lot of messages stacking up.  I've moved that polling step into its own actor so it can't block the main actor.  Thanks everyone!