Necessary Maintenance #7178
message service verbosity
0%
Description
Document standards and practices so that
a) It is obvious how to send a message that will always be printed in its entirety
b) The pre-scaling behaviour is more obvious to casual users of the message facility
Change message facility if necessary to make the above true.
History
#1 Updated by Christopher Green about 5 years ago
- Status changed from New to Feedback
a) This should be a subtask.
b) Rob has agreed to produce a first draft proposal for discussion by stakeholders.
#2 Updated by Rob Kutschke about 5 years ago
In this note I will address 2 things.
1)
What behaviour do I want for the "Starting the nth event" heartbeat message.
2)
What behaviour do I want to for other sorts of messages.
Here we go:
1)
The behaviour that I would like to see is as follows. The behaviour is characterized by a single run-time parameter. The example below gives the example for the parameter having a value of 3. In this case I would like to see event heartbeat messages on the following events:
1, 2, 3
10, 20, 30
100, 200, 300
1000, 2000, 3000
10000, 20000, 30000
and so on.
I would also be happy with minor variations, such as:
1, 2, 3
11, 21, 31
101, 201, 301
1001, 2001, 3001
and so on.
An obvious question arises about what to do if I pick a number greater than 9, so that the "single digit" messages overflow into the "2 digit" messages. I don't care - just so long as nothing breaks.
The spirit is that I want to see a regular heartbeat when I am debugging a smallish number of events, which I would normal do interactively. But once I start running a large numbers of events, I don't want the log file to fill up with heartbeat messages ( and I don't want to need to change this part of the configuration between debugging and production running ).
I said that the algorithm was characterized by a single parameter but there is an implicit second parameter - this is all based around powers of 10. As far as I am concerned this can be fixed and does not need to be run-time configurable.
Another run-time configurable parameter might be the power of ten at which the backoff stops. For example I might wish to get messages every 10000 events indefinitely.
2)
About other error messsages, such as "Warning: Too many straw hits in this event", I can live with the above behaviour but my preferred behaviour is that I would get the first N such messages and no more after that, where N is a run-time configurable parameter. I would also like to have a table at the end of job that prints out how often each message appeared (maybe I only get to count on a per category, not a per message basis ).
The spirit here is that I am a looking for events to debug I can run a job to get a printed list of interesting event numbers - then can do a second pass with diagnostics turned on just for those events. The table at the end is useful for making time series plots in order to look for trends.