I have a driver with a QAction that has the precompile option specified. Some QActions are then importing this QAction.
I have the problem that sometimes when the DataMiner agent starts up, that some QActions can't be executed because the compilation fails due to some missing items. It turns out that this is caused because the missing items are part of the precompile QAction. Investigation shows that the precompiled QAction was not compiled, hence preventing the other QActions that rely on this from executing.
When I restart the element then the precompile QAction gets compiled, and everything works fine again.
I'm wondering if there's a way to call the compilation of the precompile QAction without restarting the element (these are quite heavy loaded elements and it takes a bit to restart) ? Can this be done by some SLNet call? Or should I add a trigger parameter to the driver on such a QAction with an empty Run method (but then code analysis will probably make a notice), or can the Run method be even omitted without further causing issues?
You can force the compilation by having a normal trigger after start up that will end up running your pre compiled QAction, that's normally a good way to debug what is happening since then you have the compilation log (in case of errors) in the element log file.
Maybe it wont fix your issue, but should at least give you more information on what is happening.
"Investigation shows that the precompiled QAction was not compiled,"
...
"When I restart the element then the precompile QAction gets compiled, and everything works fine again."
This seems counter intuitive. Usually if a precompile hasn't compiled it's due to exceptions and compilation problems. Restarting the element should have had the exact same effect and still fail to compile.
I've never come across a situation where a precompile simply didn't happen (unless, like mentioned above, it has exceptions)
On what DMA Version have you seen this behavior?
It’s seems extremely likely that this is an issue linked to the splitting of SLScripting then. From the original tasks & release note (13123) on this feature it mentions having to create a dll for each SLScripting.
It’s likely that the precompile option used, which tries to compile at startup of element isn’t playing along with the SLScripting split.
If it’s possible to locally simulate this problem on the latest dma feature version, this can then be added to a task for our software dep. to look into.
As a workaround, you should be able to add a Run method and then call that. It will force a compile without issue.
You’ll have to add comments and possibly suppress some errors to make sure no-one removes your workaround. Best to also add the DCP Task ID of any software issue task you created.
Just remember not to ‘do’ anything in the Run method that tries to use ‘shared’ data, it won’t match with the data other QA’s will try to access.
You’ll also have to make sure you trigger the precompile before anything else to make sure this is stable. (so no running timers, no after startup quickaction using that precompile)
This happens on a 9.5.0.0-7607 (CU10).
Also have to mention that there are multiple SLScripting processes active. Some elements running the same driver on the same DMA execute correct, their precompile QAction dll is present in the ProtocolScripts folder. Seems like for some other elements the precompile didn’t get called in the first place (no issues in the QAction code to avoid the code from compiling).
Perhaps I should move again to the old school way before we had the precompile option and force the QAction to run via startup trigger so the compilation does get called.