{{toc}}

The Issues associated with Message Logging and TRACEing

Consistent Message format

There most likely should be. Should single line message (without an “end of message” indication) be allowed?

Log Message Destination(s)

cout/cerr vs. log file

Some libraries write “log messages” (error, warning, etc.) to cerr. To have these message and
mf message go to the same destination, we could configure message facility to use cout/cerr and
then redirect those streams to a file. Note: unix allows the process to redirect it’s own streams.

Message rate (fast vs. slow) vs. Long term archival vs. Short Term Overwrite

Writing messages to log files — at some rate there will eventually be back pressure.
Messages can be dropped to postpone or eliminate the backpressure. Should that be viewed as an indication that the application is
logging (to files) too many messages and that the logging needs to be adjusted?
One message destination may not be appropriate. Many people may not think that there
is more than one or they might only ever want to look in one place. When debugging, it
may happen that an excessively large volume of message are written to a log file, which
in addition to creating large unwieldy files, can adversely effect performance. These issues
are mitigated by directing debug logging to a circular memory buffer.

How important is the mf’s message rate limiting feature?

combined destination

One file with messages from multiple nodes.

Precision (more vs. less) (where’s the line?)

What time resolution is needed? Seconds? Milliseconds? Microseconds?
If microseconds are needed, how likely would it be to need CPU and thread (tid) information?

Verbosity - when all is well vs. when there is a problem

There are many details which are not needed when all is well. When there are problems, should the
messaging be able to show interactions with other programs and/or the OS? Should the details be selectable?
Without recompiling?

Initial Debugging - the tendency to use the wrong destination

“Success/Info” logging should go to an obvious location. If a system issue comes up and more info (logging)
needs to be added, should newly added log messages (“debug information”) be directed to the “Success/Info” (obvious) location?
If TLOG_{DEBUG,TRACE,ARB) messages are added, these message and be run-time/dynamically directed to the “Success/Info” location.

At the Limits of Rate

In a relative sense, computers are good at binary calculations and data movement and they are not
as good at converting numbers (especially floating point)