Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Actors appear to shut down, but still lock their libraries. Code included.

Solved!
Go to solution

Jed394 wrote:

So maybe I'm not keeping up here but if you are saying that the bug is inherent to the ABCR function, then under what circumstances should we avoid using it outside of the actor framework?

Clearly the ACBR node is not broken universally or we would never have passed LV's nightly test suite nor would we have many users successfully using it. But it does break sometimes. You should be ok as long as one of the following is true:

a) You are not calling Open VI Reference multiple times for the same VI OR

b) If you are calling Open VI Reference multiple times for the same VI, any given "open ref - use - close ref" sequence does not overlap in time with any other such sequence.

Jed394 wrote:

Should the ABCR be avoided in all cases unless patched? 

See above.

Jed394 wrote:

Does this bug have any effect on executables or is it only within the development environment? 

Any bug in the functionality of a node will affect both executables and dev environment. It is theoretically possible for them to differ, but we go to pretty great lengths to ensure those match as much as possible. In this case, yes, it affects both.

Jed394 wrote:

Would you consider this a major bug in the ABCR node, given that it does affect how it tracks currently open vi's.  If so why would this not be patched in older versions of labview. 

Yes, it is a major bug. It would not be patched in older versions of LabVIEW because it is not NI policy to patch older versions at all unless it is creating a showstopper for a large account that cannot upgrade. Patching older versions is very risky (and we have screwed it up in the past) since they lack the massive testing exposure of an alpha and beta release cycle. It also requires enormous effort from many developers to revalidate the entire NI software stack for a patch. Since there is a workaround available for this bug, it further decreases the likelihood of a patch. I am not defending this policy. I am stating this is the policy. If you disagree with the policy, there are other forums to debate it.

Message 41 of 60
(2,597 Views)

Hey, everyone!

Here is the KB entry on this issue:  http://digital.ni.com/public.nsf/allkb/2EE8B4884922F2E686257D580053BDB1

Not much there that we haven't discussed, but there are links to replacement Launch Actor VIs. for 2013 and 2014.

As Stephen mentioned, we expect to ship the fix in 2014 SP1.

Message 42 of 60
(2,597 Views)

Way cool. Thanks so much!

Danielle

"Wisdom comes from experience. Experience is often a result of lack of wisdom.”
― Terry Pratchett
0 Kudos
Message 43 of 60
(2,597 Views)

Hey Mike_Le we came across this as well and I think we're on the same page as you

I'd like to expand on this and we how we've dealt with this at Prolucid

Here's the original case

originalAF.PNG

you can see the link on the unintiialized shift registers that Mike_Le is talking about

AF_Fix.PNG

Above we can see an initialize on the shift register that solves the locking library problems. This was the fix we've gone with. The crappy side is it's super slow.

Now in 2014 (haven't confirmed back to 2013, would love to hear feedback from someone who is experiencing this probleim in 2013)

AF_FinalFix.PNG

This solves the locking library issue and the performance issue.

If anyone is repro'ing the issue in 2013: the second last image will fix your problem. But please give the last image a shot and report back if it fixes it as well as it will provide a substantial perf improvement

weird benchmark details

2nd last image 1500 actors : 35 seconds

last image 1500 actors same system: ~5 seconds

0 Kudos
Message 44 of 60
(2,597 Views)

AQ, The "leave launcher running" fix seems to be working. I did not change the code in actor core (using the examples, downloads or otherwise). I changed the launcher to keep running until it receives the last ack from the controller. So far, no locked libraries. Thanks for the suggestion!

"Wisdom comes from experience. Experience is often a result of lack of wisdom.”
― Terry Pratchett
0 Kudos
Message 45 of 60
(2,597 Views)

Wcoletto, thanks for your sharing.
I have around 60 actors but only 10+ actors running parallelly at the same time.
Before the patch I found sometimes it takes from few seconds to over 10 seconds to close whole program.
After the patch it will close within 3 seconds.
I'm using LV2013.
Hope this info helps.

Ryan

0 Kudos
Message 46 of 60
(2,597 Views)

I have LabVIEW 2014SP1 and I am noticing when I shut my application down that the libraries remain locked. Sometimes in the runtime, the executable doesnt completely shut down either. My top level launcher launches the root actor, and then shuts down. Is this what is causing my problem?

0 Kudos
Message 47 of 60
(2,597 Views)

Do you have PPLs? If so, then your top level launcher should shut down only when your application is done.

"Wisdom comes from experience. Experience is often a result of lack of wisdom.”
― Terry Pratchett
0 Kudos
Message 48 of 60
(2,597 Views)

no I dont have packed project libraries in this project.

0 Kudos
Message 49 of 60
(2,597 Views)

I am still seeing this intermittent problem with the libraries locking after shutting down the application. Most classes are actors, some are not. I am performing housekeeping on all of my actor classes and closing references on the stop core vi. I did try leaving my top level launcher running until I shut the application down and then it closes out. It works the first time I run it, and then the second time is when the locks in the libraries are happening. I am also noticing that occassionaly my executable hangs and I have to use the task manager to shut it down.

I am developing in LV 2014SP1.

0 Kudos
Message 50 of 60
(2,597 Views)