-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix race condition in DAQ modules when exception is thrown in event processing (only affecting multithreading) - 80X #12202
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Prefer prefix ++/-- operators for non-primitive types
Tracking Reco: tuning of outlier rejection, duplicate merging, pairSeeding
…agger-Retuning HBHE isolated noise reflagger retuning for Run2
3prong1pi0 new dms
Rename Create Bd_JpsiKPi.dec to Bd_JpsiKPi.dec
Python3 and recent python 2 use sys.maxsize and no sys.maxint
…iseFilter-to-25ns-V2 Switch default HBHENoiseFilter settings to Run2-25ns configuration V2 - 76X
There was no point to have it static anyway.
Make them members in Vx3DHLTAnalyzer. Please test before accepting.
Monitoring service changes for DAQ: rebase (80X)
Do modern exceptions after conflicts resolved
Add Phase1 pixel and Phase2 (2023) eras
…g, with other thread already requests next event from source. Source can then open next LS (internally) and report event number in past LS to the FastMonitoringService. In this case it is possible to run preEndLumi triggered by exception later than source report, in which case exception check was (incorrectly) being skipped.
compilation fixes Conflicts: EventFilter/Utilities/interface/FedRawDataInputSource.h
…ssw into test81 Conflicts: EventFilter/Utilities/interface/FastMonitoringService.h
Pull request #12202 was updated. @diguida, @ianna, @cerminar, @fabozzi, @covarell, @bendavid, @vanbesien, @govoni, @civanch, @srimanob, @cmsbuild, @davidlange6, @vciulli, @Dr15Jones, @mdhildreth, @deguio, @ggovi, @vadler, @mmusich, @mulhearn, @danduggan, @boudoul, @thuer, @monttj, @franzoni can you please check and sign again. |
Not sure what went wrong in rebase. Closing this one and will make a new PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Port of #12200 (75X) and #12201 (76X)
A rare race condition occurs when exception is thrown during processing of last few events in a file and LS. In this case, another thread can already request next event from the source. If next event belongs to the next LS, input source reports to the FastMonitoringService a total number of events in previous LS.
Normally in case of exception, we skip writing JSON stream output (catching exception action callback in the FastMonitoringService), and subsequently hltd assigns missing events as error events to close micro-merge of that LS. However, suppression was not happening after input source already reported the total number of events to the FastMonitoringService. This lead to incomplete micromerge for some streams. The problem is present only in multithreading, as in the single-threaded mode source can get a request for next event before exception on currently processed event is thrown (i.e. event requests are aborted and run/LS get closed).
In this update, JSON output is suppressed if exception has been thrown, regardless of input source report.