I have an Qaction A that receives changes from a table and triggers Qaction B. Qaction A writes to an invisible string "buffer" param that Qaction B reads from and deletes. The problem is that the table may have multiple changes. So as Qaction A is triggered multiple times it also triggers Qaction B multiple times. So depending on when Qaction B is scheduled to run the buffer may not be completely filled with the changes. Is there any way to tell how many times Qaction A is scheduled to run, and then run Qaction B when its finished? Can I see how many changes are in the table? Or is this just a bad pattern all together?
Hi,
Is this table an SNMP table and is the QAction A triggering on this SNMP table?
Does the QAction A have the row="true" attribute specified? If that is the case then the QAction will go off multiple times when multiple rows are changing in the table. Remove the row="true" to have only one trigger when things are changing in the table.
To avoid having to work with a buffer parameter can be done by importing (precompiled) QAction B into QAction A. This way QAction A can directly use the methods of QAction B and pass the "buffer" value to the B method instead of having to go via a parameter that would have a more costly inter-process call.
If the code of QAction B is not shared with other logic that would be triggering this QAction then this code might as well be directly added to QAction A.
Regards,
Hi, I took a look at the Harmonic VOS that was mentioned in the reply to the answer of Michiel. Writes enter on QAction id 1000, this then modifies the buffer parameter 999 and starts group 998 that processes the buffer values on another thread in QAction id 998.
1) Is there a way to know how many sets/writes are still waiting to trigger QAction id 1000? No, there is no way to know this. QAction 1000 will be triggered set per set. This means if group 998 gets triggered fast enough that it could send multiple commands to the VOS instead of one with all items.
2) As QAction 1000 and 998 run in 2 different threads, it means that there could indeed be a race condition where both will be writing the buffer at the same time, which could result in items being handled twice or not at all. A locking mechanism will be needed between both QActions, or instead of working with a parameter, work with a shared thread safe queue or stack object between both QActions where items can be added/removed
No, this is a displayed table; Qaction B handles several triggers. To be clear I did not write this code. I would still need to know when the params are done triggering in Qaction A before I could call the methods in Qaction B. But because the write params directly call Qaction A I am unaware of a way to know how many changes were made