Better handling of TriggerResults consumes in PAT Trigger modules #19259
Conversation
If the module is told to automatically determine what process to get the TriggerResults from, the code will now skip the current process TriggerResults. This avoids problems where the module is placed on a Path instead of an EndPath or being run unscheduled.
|
A new Pull Request was created by @Dr15Jones (Chris Jones) for master. It involves the following packages: PhysicsTools/PatAlgos @perrotta, @cmsbuild, @slava77, @monttj, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
please test |
|
The tests are being triggered in jenkins. |
|
Comparison not run due to runTheMatrix errors (RelVals and Igprof tests were also skipped) |
cmsbuild
added
comparison-notrun
tests-rejected
and removed
comparison-pending
tests-started
labels
|
please test |
cmsbuild
added
comparison-pending
tests-pending
and removed
comparison-notrun
tests-rejected
labels
|
The tests are being triggered in jenkins. |
|
Comparison not run due to runTheMatrix errors (RelVals and Igprof tests were also skipped) |
cmsbuild
added
comparison-pending
tests-pending
and removed
comparison-notrun
tests-rejected
labels
|
The tests are being triggered in jenkins. |
|
This change was shown to solve the problem seen in this hypernews threads: |
|
@cmsbuild please test |
|
The tests are being triggered in jenkins. |
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
|
@Dr15Jones |
|
@slava77 Before the implementation of sub-Event level multi-threading, if the module was on an EndPath it could get the current process' TriggerResults while if it were on a Path that lookup would fail. The old code was relying on this 'fail to get current' in order to work. After the implementation of sub-Event level multi-threading, the framework looks at the consumes information and can tell that if a module requests a TriggerResults for the current process but the module is on a Path that it is impossible for the TriggerResults to even be gotten and therefore there is a scheduling problem. It is still possible to get this new code to get the current process, one just needs to explicitly say it must come from the process by using the process name and the module must either be run unscheduled or be explicitly placed on an EndPath. |
|
On 6/17/17 6:25 AM, Chris Jones wrote:
It is still possible to get this new code to get the current process,
one just needs to explicitly say it must come from the process by using
the process name and the module must either be run unscheduled or be
explicitly placed on an EndPath.
good to know that overall there is no loss in functionality.
Thank you for the explanation.
|
|
merge |
If the module is told to automatically determine what process to
get the TriggerResults from, the code will now skip the current
process TriggerResults. This avoids problems where the module is
placed on a Path instead of an EndPath or being run unscheduled.