Best way to handle config files in AF

[cirrusio]

Hmmmm....you just taught me something new.  From the help :

You cannot use notifiers to communicate with VIs on other computers. For example, you cannot use notifiers to communicate across a network or the VI Server.

Since each actor is loaded asynchronously via VI Server, make sure that your obtain session is located within the actor of interest.  Putting the obtain in the Pre-Launch Init should be sufficient.

Cheers, Matt

[testingHotAir]

Ah ha!  That does pose a problem for me though.  I'm using some of the configuration data to search for plugins to load in the later steps of my Load App vi, which is why I'm reading the config file before launching.

I could read the config file from a single-use reference that I then close before I launch the actor.  Seems a bit sloppy though.

[testingHotAir]

Sloppy, but it works!

[cirrusio]

Hmmm...it's not clear why this is a problem.  Presumably you will have a controller which will sort through the config file and determine what needs to be launched.  You don't need to pass the config file, just the name of the session and location; or this can all be contained within the pre-launch init itself; or there may be another way.  Regardless, you do not have to obtain the session within the actor launching the nested actors, that should be able to be done within the context of the actor of interest.  Does this make sense?  This is how I use the session configuration.

[testingHotAir]

Ah but the root actor in this case also needs a session of the config file.  On each launch of a nested actor, I'm obtaining a new handle for that nested actor.  The problem was that the root actor had a different session - and therefore a different copy of the config file - than the nested actors.  Each subsequent nested actor launch had the correct behavior.

[drjdpowell]

I think your issue is due to the DVR created in the ESF, not the named Queues.   Named Queues can outlive their initial creator, as long as some other VI hierarchy holds a reference to it.   But a DVR is a single reference owned by the first creator of a session, so if that creator is your launcher then the DVR will die with it.

A related ongoing LAVA discussion.

[cirrusio]

Thanks James.  I actually think you are spot on, but I will look to verify.