@tsulaia pointed out that when we write raw files the we grab run parameters from the input metadata store. That is dangerous as that store is cleared each time a new input file is opened. This prompted me to work over our ByteStreamEventStorageOutputSvc.
First we nor grab the run parameters from the metadata store filled by the metadata tools. As @wlampl suggested, a warning is raised when multiple copies of the ByteStreamMetaData are found. The run parameters from the first object are selected. This is a limitation of the bytesatream format.
Run parameters are used from sources multiple sources with the following priority:
- The job configuration
- The
xAOD::EventInfo - The ByteStreamMetaData
- The ProcessingTags
- defaults
The information is needed to set up the data writer, either on the first putEvent that is called or when MetaDataStop is called to write out an event-less file. To avoid a large number of logic paths the parameters are taking in reverse order: job configuration parameters overwrite the content the parameters set by
xAOD::EventInfo,xAOD::EventInfooverwrites those from the in-file metadata, and so on. The component accumulator configuration has been adapted such that thexAOD::EventInfo,ByteStreamMetaDataandProcessingTagsshould be available when the job is configured for bytestream file output. Objects are retrieved via ReadHandles to help the scheduler decide when the bytestream output has the information it needs,
Events to be written are cached in a slot specific object for write out. The cache itself my be superfluous (let me know your thoughts). I could not think my way out of two things that need locking: the initialization of the DataWriter and the writing of events to file. Since the two things happen one right after the other there is a single lock making making sure only one thread does this at a time --- should we ever end up in a scenario where this service is called by a threaded output algorithm.