Necessary Maintenance #7178

message service verbosity

Added by Lynn Garren over 6 years ago. Updated over 6 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
SSI Package:


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.


#1 Updated by Christopher Green over 6 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 over 6 years ago

In this note I will address 2 things.

What behaviour do I want for the "Starting the nth event" heartbeat message.

What behaviour do I want to for other sorts of messages.

Here we go:

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.

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.

Also available in: Atom PDF