CMS MessageLogger: Open Issues Concerning Features Wanted by CMS

CMS MessageLogger Service
Open Issues Concerning Features Wanted by CMS


Multiple Message Categories

The requirement

A message can be issued with multiple categoriess, as in
  edm::LogWarning(tracking&overflow) << "some more text";
This is to be treated as both a category=tracking message, and an category=overflow message.

Questions

What does it mean to be two types of message. The easiest thing to do would be to issue two distinct messages but assumedly that is not the most desirable behavior. The questions include:

Proposed treatment

When a message is issued
  edm::LogWarning(tracking&overflow) << "some more text";
message counts for both "tracking" and "overflow" ID's are incremented. If a given destination would react to either a "tracking" message or an "overflow" message, it will react to this message, but only a single copy of the message output will appear.

In that message output, the category will look like tracking&overflow, and even if the combined length is longer than the normally permitted length the full combined categoriess will appear.

Statistics destinations will note the appearance of one "tracking" message and one "overflow" message; thus the total of counts by message ID will no longer match the total of counts by severity. The context (of the first two and last one of each type of message) kept by the statistics destination will react as it would to a single message of each of the categories. Thus it is possible to have the same context (event number or whatever) noted twice (in two different categories) caused by this one error message.

Work consequences

The "issue the message twice" attitude would require no work on ErrorLogger internals, and routine work in the LogXYZ() functions. However, that is not the desired behavior.

The above proposal will require modifying the nature of a message ID within ErrorLogger. At some points it is a potentially compound ID; at others (for example, in the limit maps and statistics maps) it is exactly as before. This is non-trivial, as the messageID penetrates much of the package, but as long as the behavior to shoot for is well-defined, this appears to be a solvable task.

Decision and Plan

The proposed treatment described above is agreed upon. In order that the user be able to use the multiple-category syntax as soon as possible, we will temporarily implement the double-message treatment.

Destination Reporting to log4cplus

The requirement

We need a destination which, rather than sending to a file or ostream, delivers the header and text of the message to the CMS log4cplus facility.

Questions

What do we do to use log4cplus, and what options does it have:

Proposed treatment

Work consequences

There are three potentially significant areas of work:
  1. Understanding how to use log4cplus may be easy (especially if the product is mature and well documented) or arbitrarily hard. We can give no estimate on how long this will take until we try it out.
  2. Creating the ELlog4cplus destination will be some non-trivial but fixed amount of semi-routine work, since it is done with some knowledge of how ELoutput works.
  3. Providing the parameters to control flexibility will take about half a day per parameter, once we know what sort of .cfg control (if any) is needed by CMS.

Decision and Plan

Instead of the proposed treatment, we have created a MLlog4cplus service which ensures that an ELlog4cplus destination is attached to the logger. This has the advantage of cutting any dependencies of MessageLogger on log4cplus (which is in xdaq). The log4cplus capability is as of 12/23/05 in place and tested. It is up to the user to deal with log4cplus, in particular, to assign whatever appenders are needed for the job. Two temporary conditions are left:
  1. We currently assign a file_appender writing to log4cplus.output whenever the MLlog4cplus service is specified in the .cfg file; it is probable that CMS will want to change this default action.
  2. We have not yet done the work to allow the user to control, via the .cfg file, MessageLogger filtering of the ELlog4cplus destination.

Probing for whether a message will be reported

The requirement

User code may sometimes generate messages which under many circumstances would be ignored by all destinations. It would be desirable to be able to quickly probe whether any destination would respond to a given message severity and category, so that the work of preparing and formating the message items can be skipped if appropriate.

There are two potential modes of usage for this capability. The naive mode is to do the probe each time a message is to be prepared. Another mode is to assume that the result of this probe will remain static, and to cache either the first result or the first negative result. In that mode, a message which would be ignored will cost only one conditional on the cached boolean.

Questions

Should we also try to automate this checking, to avoid the cost of the operator << when the user appends items to the line to log a message?

Since the cost of a probe will not be trivial, should we cache results and consider the probe of each message type to be a one-shot affair? That is, if you have learned whether this type of message is reported, should we assume that this answer will not change. This is not strictly true because of limits, but it may be a useful shortcut.

Proposed treatment

Create 4 new functions:
  ProbeLogError   (const std::string & category);  
  ProbeLogWarning (const std::string & category);  
  ProbeLogInfo    (const std::string & category);  
  ProbeLogDebug   (const std::string & category);  
These would return true if any destination would respond to the corresponding message.

The first time a message type is probed, we must issue some sort of special two-phase command to the MessageLoggerScribe, and it must cause an actual check useing ErrorLogger code. Once a message type has been probed in this way, the answer will be cached. We should implement this cache via a map (in the local thread, to avoid the complications of locking against new entries by other threads) of all messages already probed. When the same message type is probed again, the map is consulted.

In order that we eventually get the efficiency of rapidly ignoring which were previously reported but have reached their limit, when a true result is found in the map, one time in about twenty we should re-check.

We can automate the check of the cached map to occur whenever messages are issued. (The user still has the option of probing to avoid work to prepare the items to be added to the message.) The rules would be:

However, we can check the local map: if a message has already been probed and found to be ignored, then the operator << can become a no-op.

This presents another mode of usage, one which we can recommend: The user probes a message category just once, and relies on the system to obviate extra work by automatically checking when appropriate.

We do have to warn about the effect of this on message statistics: Messaages which are sent to the logger but ignored make it into the statistics, but messages which are never even sent do not. (Assumedly, the user would not care about the count of messages in categories which are completely ignored.)

Quick temporary treatment

We can quickly implement the propbe functions as returning true, thus allowing user code to start using this mechanism (with no efficiency gain until we implement the actual probing) immediately. This treatment is now in place.

Work consequences

The ErrorLogger currently has no means of probing for responding destinations. This will need to be created. The difficulty should be moderate (time estimate of 1 day).

The MessageLoggerScribe will need a new opcode to do the probe. The probe data structure would be a pointer to one integer (not a bool, because the probing end has to know when the result is now valid). The probe routine (on the client side) will need to either sleep on that value changing, or otherwise wait till the true/false value is established. This is not as easy as the other part, but probably will take another 1 day.

The establishment of the cache will be easy, but the re-writes of LogWarning etc. to take advantage of known non-response results will be subtle. In particular, the LogDebug macro may be very subtle if we don't want to take the cost of forming and passing __FILE__ and __LINE__ when we don't have to.

The total time estimate for this feature is three solid days.


Statistics Destination

The requirement

The ErrorLogger has a nice ELstatistics destination for summarizing the messages.

We need a way for MessageLogger service users to to specify a statistics destination.

Questions

Proposed treatment

Work consequences

Other than the context issue, we can probably set up statistics in a day.

Other Filtering Options

The requirement

The ErrorLogger package supplies other ways to specify limits and thresholds on which messages a destination will report. For instance, one can set a limit for all message IDs except a specified type. The MessageLogger service might benefit from enabling some of these further options via the configuration file.

This requirement may or may not finally be requested.

Questions

Proposed treatment

Additional parameters in the .cfg file, either destination-specific lines within the destination PSet, or general lines within the service=MessageLogger PSet.

Work consequences

Requires no modifications to the ErrorLogger package. However, each degree of flexibility will require code in MessageLoggerScribe to understand the parameter and issue appropriate calls to the ErrorLogger. Also, each feature requires CMS MessageLogger service documentation (otherwise it is next to useless). The total time to enable a feature is about half a day.

Context (e.g., event number) in Messages

The requirement

The ErrorLogger package supplies ways to automatically append context information to messages. The intent is to indicate event/run numbers without the message issuer having to think about it. Perhaps the MessageLogger service should support this.

This requirement may or may not finally be requested.

Questions

What should we use as the context?

Proposed treatment

We find out how to get context from an existing EDM service, and write a context supplier (in the ErrorLogger sense) to do so). We propose that the format of the context not be user configurable.

Work consequences

Requires no modifications to the ErrorLogger package. Writing the context supplier is likely to take less than a day, assuming the info is available from the EDM.

Support For Use Of endl in Messages

The requirement

Users are used to using std::endl as a line terminator. The use of \n is already supported for this, but it might be desirable to also support endl.

This requirement may or may not finally be requested.

Questions

Is endl any different in effect than \n?

Proposed treatment

The ErrorLogger package implementers originally attempted use std::endl as a message terminator. This led to technical difficulties we could not, at that time, surmount (thus the introduction of the errmsg manipulator.

Jim Kowalkowski and Marc Paterno claim they know how to do this without those difficulties. If so, we will adapt that technique, treating endl as a "force line termination" directive (as opposed to a message terminator).

If this is not easy, we should not do it, as the gain is slight.

Work consequences

Requires learning how to handle endl, and implementing that in ELoutput and other destinations. The danger is that the problem issues may be subtle, in which case it is best to abandon the idea.

Multi-statement Building of Message Objects

The requirement

In the ErrorLogger package, the user can gradually build an ErrorObj containing th message, and later dispatch it ot the logger. A similar capability might be desirable in the MessageLogger service.

This requirement may or may not finally be requested.

Questions

Proposed treatment

The ErrorObj in the ErrorLogger package already has its severity and ID imbedded upon construction, and we propose to do the same here. We would provide 3 classes (the Debug form has complications we choose not to deal with: InfoMessage, WarningMessage, and ErrorMessage. The ctor would take the message ID.

The user community would probably vote for some sort of send() member function or special endmsg manipulator to indicate that the message is to be dispatched, but this leaves around a dangerously already-sent message object. The correct idiom is to dispatch the message when the object is destructed. The user code should look like:

  if ( problem_is_detected ) {
    WarningMessage warn ("thistypeoftrouble");
    warn << "information is";
    while (there_is_more_information) {
      warn << get_a_piece_of_information(); 
    }
  } // here warn goes out of scope and the message is dispatched

Work consequences

This would be straightforward since no ErrorLogger code need be modified. Including documentation it should take a couple of days.

Post-configuration Control of Logging Behavior

The requirement

The current service allows control of the behavior of destinations (filtering and thresholds) and the overall logger, only via job-start configuration parameters found in the .cfg file. We could also support modification of these choices under programmatic control.

This requirement may or may not finally be requested.

Questions

Proposed treatment

We immediately step onto a slippery slope (more like, step off a steep cliff) when we open up the idea of runtime control of these options. Developing an interface for this control would take weeks at the least, and there would inevitably be arguments over all the equally-good ways of expressing the desired behavior.

The only sensible answers are to provide no post-configuration control at all, or to provide everything in the ErrorLogger package. In the latter case, the capability is provided by having the service provide points or references to the actual ErrorLogger package objects, such as ELadministrator and the various ELdestControl handles. The user would need to look in the ErrorLogger package documentation for how to use these.

Work consequences

If we can stick to our guns about just providing handles to raw ErrorLogger objects, this should not be too hard. There may be a bit of work in developing an interface to get the ELdestControl for a given destination, but we probably already have the structures in place for that.

If we need to develop a separate CMS-approved interface for post-configuration adjustment of behavior, this will be a hopeless and endless task.

USCMS Software and Computing Home Page - CMS MessageLogger Service Page


Mark Fischler
Last modified: December 1, 2005