Warning, /FWCore/MessageService/doc/pre-presence-plan is written in an unsupported language. File is not indexed.
0001 How to Deal With Messages Before the MessageServicePresence Exists
0002 ------------------------------------------------------------------
0003
0004 When a message is issued, the MessageSender causes (via a MessageLoggerQ
0005 method) something to be placed onto the SingleConsumerQ. In the current
0006 implementation, for each message a buffer on the queue is obtained, and
0007 the message is placed into that buffer, which is then committed. The code
0008 blocks if no buffer is ever going to be available (which would be the case
0009 if the MessageServerPresence were never instantiated).
0010
0011 We want to be able to cope witht he case of many messages issued before the
0012 MessageServerPresence exists, prinicpally to be able to handle "debug-level"
0013 information issued by the plug-in manager itself. As long as the number of
0014 messages does not exceed the queue capacity (1000), there is no problem:
0015 Once the presence is instantiated, the run() method will take care of dealing
0016 with each message in the order in which they were received. The destinations
0017 will not have been configured yet, but at least the information will go to
0018 cerr. (One could decide on a different pre-configuration destination, but
0019 that is a separate issue.)
0020
0021 What we want to add is some suitable behavior in the case where the queue
0022 capacity is exceeded before the service presence has been instatntiated.
0023 The current "suitable behavior" would be to put the message onto the queue
0024 **only if there have been fewer than 999 such messages so far**. If the queue
0025 depth is exceeded, then queue (once, as the last viable entry) a system-level
0026 message about further messages before configuration going to cerr, and
0027 route the string of the message to cerr. A minor modification to this is to
0028 say that if there are multiple consumers, each has some known share to use
0029 in place of 999.
0030
0031 Of course, once the presence is instantiated, the current policy of just adding
0032 the message to the queue is proper. The best way to implement this decision
0033 is by installing one or the other "policy functions" as the action which
0034 normally corresponds to queue-ing up the message. Then in the future, if
0035 the nature of the queue changes so that we could implement other options
0036 (such as "drop the initial entries and queue the new one), we can merely write
0037 and install some different policy function.
0038
0039 ---
0040
0041 A separate issue - the pre-copnfiguration messages come out on cerr.
0042 Maybe there would be an advantage in delaying logging till logger configuration
0043 has happened; then they would come out in the desired destination files.
0044
0045 The problem is that by delaying the output, you ensure that if the problem is so
0046 severe that the job never gets to the configuration step, the developer gets
0047 no output, thus no clues as to what went wrong.
0048
0049 A "modified limit hangout" might be to push each pre-config ErrorObj onto
0050 a vector of them (we could conceivably want to limit the total size of this
0051 vector) along with logging it to cerr. Then at the tail end of configure_errlog
0052 we could log each of those objects in the normal way!
0053
0054 ----
0055
0056 When should we do these things?
