Dear Experts,
We struggle to properly configure our PP task which is working synchronously.
The Task (normal, not PP) has cycle=5min and produces 2 objects: TriggersCorrelation and CycleDurationNTF.
We would like the PP to compute ratio of values extracted from these objects after each cycle.
Therefore we set trigger to:
Then when PP is triggered after 2nd cycle it searches for objects valid at time=TRG2, so for CycleDurationNTF it’s v2 but for TriggersCorrelation it is v1 because v2 is uploaded after TRG2 and therefore v2 is not valid at TRG2.
Is this correct?
Is there a way for PP to wait until both objects are updated? Something like “OnAll” policy used in checkers.
For now it depends strongly on the order in which objects are uploaded in DB (tiny differences) which does not seem to be a good idea.
One solution is to move this functionality to normal task, however it would be better if we could achieve desired behaviour using PP.
Second is to trigger on the TriggersCorrelation object, but again, we don’t want to rely on their order.
Hi, I do not have a solution on the top of my head which I can call perfectly clean, but perhaps you could use both triggers and check in your code if both objects are ready. You could even store the latest version of both and generate the results only if you know they both correspond to the same cycle.
Please let me know if I am missing something here.
Well, it looks reasonable to trigger on both objects, each time get both from CCDB and simply compare their timestamps. Not the prettiest but maybe enough.
In any case, please be aware that you are not guaranteed that objects from different tasks have the same data inside even if they come from the same cycles. This is because:
the Dispatcher may sample data differently (but you can configure it to sample the same timeframes)
we randomly shift the cycles in order to decrease the load on the network and Mergers
Ah, I understood they are from different ones. Small time misalignment of objects from the same task is actually something i want to fix anyway: Cern Authentication
Once this is fixed, you should not need the workaround.
(…) I have to make sure that the one I choose to trigger upon is the earliest in QCDB, otherwise the trigger timestamp will not match some of the others
– this is exactly our case. Yeah, it would be great to have such fix.
Do you have ETA for this? Maybe there is no point to implement a workaround on our side…