CMS MessageLogger Service: Frequently Asked Questions

As developers begin to use the facilities of the MessageLogger service in increasingly selective ways, it is inevitable that questions arise about how to accomplish various things. As those questions arise, certain themes recur, eventually achieving the status of Frequently Asked Questions. This page is our attempt to provide answers to those questions.

 


  1. Dealing with the MessageLogger from non-cmsRun applications

    How does one issue messages from a "stand-alone program?" [By stand-alone, we mean a program where the user supplies the main program rather than going through

    cmsRun].

    What happens to messages logged by the Message Logger, when the Message Service has not been initiated?

    We, in the CSC community, sometimes use "semi-standalone" programs to analyze our private CSC data such as CSC calibrations etc. These programs usually are like test.cpp main()s which utilize CMSSW CSC software in particular CSCRawToDigi unpacking. What happens to messages logged by the Message Logger during the unpacking?

    Why is my program hanging up? I'm not issuing messages myself, but other modules might be. After certain number of events the program simply stalls. The more verbose is the setting for message, the sooner it stalls.

    Answer

    Any messages which are issued go to a queue which is destined to be serviced by the Message Service. Even if the Message Service is not told to produce any destination files, messages are routed to a log which comes out on cerr.

    However, in a stand-alone program, you still have to establish the service of draining that queue to the thing that writes the log (to cerr). We have a class called MessageServicePresence -- as long as an instance of that exists, the "business end" of the service is active, draining the queue and writing out your messages.

    There are several steps the user must execute when operating standalone, most of which are handled internally when working with cmsRun. All of those steps are shown in the program Standalone.cpp in the MessageLogger/bin directory of CMSSW releases CMSSW_0_8_0_pre3 and later. We list those steps here and cross reference them to the comments in the actual code. To understand all this, it is probably best to open another window to the CMS code browser and look at the text of Standalone.cpp in the FWCore/MessageLogger/bin area while reading the rest of this answer. The steps are:

    • Instantiate the plug-in manager as shown at A.
    • Load the MessageService plug-in as shown at B.
    • Establish a MessageLogger configuration as shown at C.
    • Create the MessageLogger service as shown at D.

    • Make the MessageLogger service available as shown at E.

    If your application cannot make use of the plugin manager, yet uses modules that issue messages, then you may be able to establish the MessageService draining this queue as follows:

      #include "FWCore/MessageService/interface/MessageServicePresence.h"
    
    And, at the start of main (or at least before a thousand messages have been issued) instantiate a presence:

      edm::MessageServicePresence my_message_service;
    

  2. Quieting information from specific verbose modules

    I need to look at the LogInfo messages issued by my application. Unfortunately, one of the modules used issues a massive number of LogInfo messages of various categories, which obscure the messages improtant for my purpose. Is there any way to suppress the messages from just this verbose module?

    I know how to enable debug messages from all modules, or from some specific modules. Is there a way to enable all debug messages except those issued by some specific modules?

    Answer

    To suppress LogInfo message from a specific module, in the MessageService section of the .cfg file, add a line like

      
    untracked vstring suppressInfo    = { "verboseModule" }
    
    or similarly suppressDebug or suppressWarning . This will cause LogInfo messages from just that module to be completely ignored, not even affecting the message statistics.

    See Configuring the MessageLogger: Suppressing Messages From Specific Modules for more details.

  3. Producing debug information without impacting production running

    I want to instrument my module with trace or debugging output, but composing this potentially useful output requires some computation. Performing this computation might incur an unnaceptable performance hit during production running, however. Is there any way I can have the output available, yet not take the performance hit when it is not needed?

    Answer

    Yes, in this matter you can have your cake and eat it too. LogDebug () is implemented in such a way that if the symbol NDEBUG is defined, then not vehicle for transmitting the LogDebug message is constructed, and the operator << used to add an item to the message is a complete "no-op".

    So if you place the computation to prepare each item into a function, the compiler need not invoke that function at all, unless it has some side effects. A way to ensure that any sensible optimizer will catch on to this, so that the run-time effect of a LogDebug statement becomes exactly zero, could look like this:

      inline std::string prepare_details() { 
        // Do computations, which may be significant work, 
        // but which have no side effects 
        // such as writing globals or using cout.
        // ...
        return theString;
      }
      // then later in the code:
      LogDebug ("somecategory") << prepare_details();
    
    
    The two critical points are that
    1. The preparation of output has no side effects -- otherwise the compiler will be forced to compile and execute it, in case you are relying on those side effects.
    2. The preparation code is inline, so that the compiler has a chance to see that never needs to be executed.

    See Controlling LogDebug Behavior: Compile-time Elimination of LogDebug Messages for more details, including how to control elimination of LogDebug processing distinctly from the NDEBUG synbol.

  4. Preventing the MessageLogger from tinkering with the message format

    I have carefully created code to output information in precisely the format I believe is most useful and readable. The MessageLogger's attempts at imposing a "one-shape-fits-all" format are interfering with this output. How do I stop this from happening?

    I have output that used to go to cout and could use various standard manipulators (such as setw()). When converting to use the MessageLogger, can I use those manipulators in my messge?

    Answer

    edm::LogVerbatim does just what is wanted here. It is a substitute for edm::LogInfo, and it simply outputs (to the various destinations) the items without imposing any formatting other than a new-line after the message is complete. LogTrace does tthe same thing when substituted for LogDebug.

    And items sent to the MessageLogger (whether edm::LogVerbatim or the other forms) can use all the standard manipulators.

    If some other thread is simultaneuously sending to the logger, then two messages sent sequentially may appear in the log separated by some message sent by the other thread. The messages won't be "jumbled," in that each message starts on a new line, but there is the chance that a table output one line at a time could be "broken up" by some other message issued in between lines.

  5. What if two destinations are configured to write to the same file?

    In my configuration, I have some destination for which I have supplied an explicit file name and extension. Unfortunately, some included configuration file also creates a destination with the identical file name and extension.

    Is this considered a configuration error, terminating the job? Or will I get duplicates of each message in a file, a jumble of messages, or some other behavior?

    Answer

    Specifying duplicate file names is considered a configuration error. A cms::edm::exception will be thrown, and if (as would ordinarily be the case for a cmsRun job) that exception is not caught, the job will terminate. Information similar to the following will be written to cerr:

      
      exception from MessageLoggerQ::CFG - exception what() is
      ---- Configuration BEGIN
      Duplicate name for a MessageLogger Destination: myname.log
    
      The preceding exception was thrown in MessageLoggerScribe
      and forwarded to the main thread from the Messages thread.
      ---- Configuration END
    

    The log files requested prior to this exception will be created, and will contain a system-level message with similar content.

    If a non-cmsRun job catches this exception and chooses not to terminate, then the effect is that the second of the duplicate destinations is ignored completely. For example, if the first destination were configured to respond only to ERROR severity, and the second to resopond to both ERROR and WARNING, the file produced would not respond to WARNING messages.

    Earlier versions of MessageLogger did not catch this configuration error; see task 4490 in the LCG Savannah for CMSSW.

-- SudhirMalik - 30-Aug-2011

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2011-08-30 - SudhirMalik
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback