Mark talked about basic concepts about the CMS MessageLogger system.
- Syntax of using MessageLogger:
LogError("category") << a << b;
- Use different interfaces for different severities,
LogDebug(). Even the same severity might corresponds to multiple interfaces to reflect different situations. E.g.,
LogProblem(), they are identically the same underneath.
- Categories could be used for message classification and filtering. There should be guidelines for the categories and the name string of each category.
- MessageLogger is highly configurable
- Multiple destination for each severity level, including local files or streams.
- Threshold decides which level of severity will be logged
- Limit gives the maximun repeating number of messages in the same category. Exceeding that, the occurance of messages will follow the exponential backoff
- Repeatevery log the message for every given number of occurance in the same category
- Use Log4cplus as the destination to route messages over the network
Structure of the MessageLogger
- Client threads call
LogError("cat") << a << bto log messages.
- The class then instantiate an ErrorObj to store the message as well as other informations like run/event, module, timestamp, etc.
- The ErrorObj will be sent to the message queue (MessageLoggerQ), which is shared by multiple threads.
- The primary purpose is to avoid conflicts and mixture of messages from multiple threads, as well as the performance consideration for user threads. E.g., an DCM dosen't have to wait until the message is actually sent before it returns to work. Send a message to the message queue could be done near instantly
- The only instance of a MessageLoggerScribe will be in charge of consuming messages from the message queue, if there is any, and send them to designated destination as in the configuration
- Codes that are mostly client orientated are in the MessageLogger package
- Server side of the codes, mostly the MessageLoggerScribe are in the MessageService package
Using Mark's MessageLogger package in NOvA
- The Message Logger could be well fit into the NOvA system
- Main problem lies in the configuration management
- ParameterSet used by the CMS configuration subsystem is deeply embedded in the Message Logger. It would not be an easy job to rip the PSet off the message logger.
- As a compromised way, we might consider to mock an PSet data object and its interface in the memory instead of introduce the whole package of the configuration subsystem from cms.