actors still running after stop core done

[dsavir]

Brian, thank you for your help!

Unfortunately this doesn't apply to me, as the VIs are definitely running, though none is top level. However, I will double check all my events to be on the safe side.

Thanks,

Danielle

[dsavir · Accepted solution]

I think I solved the problem. The problem I noticed is that the event loops in the plugin actors stop receiving events, including timeouts, after my controller launcher has shut down. It used the launch root actor VI, ran some tests and exited.

I launched instead using the deprecated launch actor VI with the message queues, and quit the launcher only after receiving last ack, and it works (also after project close and open ).

My launcher used to send  a "stop controller" at the end for easier testing, so it worked mostly; and when I removed it it still continued working for 5 seconds after launching the controller because I ran a test script, so that explains why it sometimes worked (because I manually stopped it before 5 seconds passed) and sometimes didn't.

I thought the point of using the launch root actor vi was that the launcher doesn't need to wait until the controller is done, isn't that correct? Is this because of running PPL plugins? In short, is this a bug or a feature?

Thanks,

Danielle

[AristosQueue (NI)]

dsavir wrote:

I thought the point of using the launch root actor vi was that the launcher doesn't need to wait until the controller is done, isn't that correct? Is this because of running PPL plugins? In short, is this a bug or a feature?

I *think* you are correct about the point of Launch Root Actor. Let me restate it in my own terms and see if they make sense to you. The launcher (the VI that calls Launch Root Actor) starts a root actor running. As soon as Launch Root Actor finishes execution, the launcher VI can quit and the launched root actor continues running.

Now, what COULD be happening is that your root actor could be trying to send a message to its caller. There is no caller for a root actor, so the send VI returns an error, and that error could be unhandled and leading to shutdown of the root actor. In this case, the  root actor would send stop messages to its registered nested actors, but it would quit before it gets any last acks from its nested actors.

Could that be your issue?

[Actually, any unhandled error coming out of a Do.vi will by default shutdown the root actor. Doesn't have to be a send error... that's just the most common error I've seen confuse people.]

[dsavir]

Hi,

Thanks for answering, AQ.

In answer to your question, no, that can't be the issue. I have overridden handle error to show me an error if it occurs, and it didn't; in addition, I handled the case where the caller didn't exists by checking if caller queue is a refnum and if it isn't I notify the user (without exiting, as a debug measure).

What I did see is that in my plugin X there is an event loop with a timeout to 150 ms. Using the while loop index and the event viewer, the event loop in plugin X handles timeout events until the launcher is closed, after which it receives no events and the index doesn't increment. Changing the amount of time the launcher is running changed the number of events handled. Changing back to launch root actor caused the problem to appear again, and changing back to launch actor + last ack caused it to disappear again. This doesn't happen in the framework event loops, only in the plugin event loops (my plugins are lvlibp).

I thought that maybe a plugin considers the top level VI to be the launcher, not the controller actor, so that when the top level VI stops running the plugin stops receiving events. Does that make sense?

Thanks,

Danielle

Message was edited by: dsavir

[AristosQueue (NI)]

dsavir: Can I please get your code somehow? I need to see this bug if I'm going to fix it. You aren't by any chance coming to NIWeek are you?

[dsavir]

I'll try to create a simple example and upload it. Unfortunately I won't make it to NIWeek this year, but if you feel like coming to NIDays Israel I would love to meet

[tst]

dsavir wrote:

but if you feel like coming to NIDays Israel I would love to meet

Stephen, allow me to double the invitation .

[dsavir]

Hi AQ,

Please find the example code here. I apologize for the lack of documentation etc., this is just meant to illustrate the bug.

Open Framework project and run launcher to see the bug.

The framework has a controller that loads plugins. the controller and plugin Actor core FP are shown and a counter counts the number of times a timeout event occured. once the launcher stops running, no more events occur in plugin1. Thre are more detailed explanations in the Launcher FP.

There is also the plugin project (all plugins inherit from this), the plugin1 project (which is the actual run time plugin to load) and the parent actor project (all actors in the project inherit from this). Included is the actor framework.lvlibp, without the project as I just took the existing actor framework and compiled it with no changes (LV 2014 32 bit SP1 with f2 patch). Parent actor inherits from actor framework.lvlibp.

Thanks for your help,

Danielle

[sassyaspy]

Hey Danielle,

Just a quick note, when I set a breakpoint in the Controller Actor Core to block the call to Launch Nested Actor until after Launcher has already closed, everything works fine. It almost looks like Plugin1 is treating Launcher as its caller if it is still running when Plugin1 is loaded/launched.

Also, your Launcher FP notes say that removing ParentActor.lvlibp from the hierarchy should let everything run as expected. Removing this class from the class hierarchy has not changed the outcome for me. Can you confirm this behavior on your computer?

Thanks,

Siana

[sassyaspy]

Hi again,

I've filed CAR 537679 to track the behavior of Plugin1 treating Launcher.vi as its caller (rather than Controller) if it has not finished running when Plugin1 is launched, as well as the reset-hang symptom that this issue then causes. It seems to only affect actors in PPLs that are loaded at runtime and do not already exist in memory. Good find!

Thanks,

Siana