Issue 2754: Reset of Capacity Alarm Threshold under wrap condition (log_service-ftf) Source: (, ) Nature: Revision Severity: Critical Summary: Summary: This behaviour does not seem correct. Under a wrap condition, a capacity alarm gauge threshold should retrigger once in each period between wraps, but if the counter resets every time it crosses the thresold it will trigger more often. Thus the reset of the gauge , under wrap conditions, needs to be reworded as follows: " When a log object is created with the wrap option the capacity threshold alarms are triggered as if coupled to a gauge that counts from zero to the highest capacity of the log defined (reached each time the log wraps) and then resets to zero. If a log wraps, and no records are deleted to free space, capacity threshold events shall be emitted only when all the records in the log prior to the previous wrap occurance are completely overwritten. In other words, the gauge threshold is reset to zero each time the end of log marker is crossed by the addition of a new log record. For example if a log has a capacity of 2 Gigabytes a wrap event will occur only when every time 2 Gigabytes of data have been written to the log. " Resolution: resolved, see revised text below Revised Text: Add the note specified by the X.700 series committee to the definition of Log Capacity Alarm Thresholds. Revised Text: Specification Text Section 3.2.4.11: Log Capacity Alarm Thresholds Log capacity alarm thresholds are used to warn clients when a log is approaching full. If the capacity of a log exceeds that of one of its log capacity alarm thresholds, then a ThresholdAlarm event is generated to indicate that the log is approaching full. When a log object is created with the wrap option, the capacity threshold alarms are triggered if coupled to a gauge that counts from zero to the highest capacity threshold value defined and then resets to zero. Note: A wrapping log can be viewed as a circular buffer. The margin between the highest capacity alarm threshold and 100% can be regarded as a safety factor, to allow sufficient time for log users to retrieve log records upon receipt of a capacity alarm, before those records which entered the log after the previous capacity alarm are overwritten. Resetting the hidden gauge to zero each time the highest threshold is crossed, ensures the behaviour that a capacity alarm will be generated every time the same fraction of the log capacity is written to the log, and therefore the same safety factor is maintained. In other words, every time a fixed percentage of the log capacity is written to the wrapping log, a capacity alarm is emitted. Clients that use a log should register with the log's log factory to receive the ThresholdAlarm events in order to be informed with the log is approaching full. Specification IDL No Change Actions taken: Completed. Actions taken: June 17, 1999: received issue July 27, 1999: closed issue Discussion: End of Annotations:===== From: "Matthews, David L, NCIO" To: "'log_service-ftf@omg.org'" Cc: "'terutt@lucent.com'" Subject: PROPOSED NEW RESOLUTION FOT ISSUE 2754 Date: Thu, 8 Jul 1999 10:53:10 -0400 X-Mailer: Internet Mail Service (5.5.2448.0) This mail is being sent for Tom Rutt. Please rely to whole list or to Tom directly. Mail from Tom follows: The OMG proposed issue resolutions for the Telecom Log RTF were discussed by the X.700 series meeting.. It was realized that only two of the OMG Logging Service issues were relevant for X.735 (issues 2753 and 2754). The group agreed with the proposed resolution of Issue 2753, and agreed to progress a draft corrigenda item for X.735 which makes the same correction as the proposed resolution of issue 2753. This corrigenda is needed to clarify that the availability status has the value "log-full" while under a wrap condition. The OMG proposed resolution for issue 2754 was not agreed to. After discussion which included the original editor of X.735, it was verified that the original text in X.735 (which was copied into the OMG Log function) is correct, (i.e., while under wrap condition, the underlying gauge should be reset to zero whenever the highest capacity threshold is crossed). The reason for the reset is to maintain a fixed safety factor to avoid overwriting log records without an announcement that the overwriting is about to occur. However, it was suggested that the following clarifying note be added under the existing text on wrap gauge reset. " Note: A wrapping log can be viewed as a circular buffer. The margin between the highest capacity alarm threshold and 100% can be regarded as a safety factor, to allow sufficient time for log users to retrieve log records upon receipt of a capacity alarm, before those records which entered the log after the previous capacity alarm are overwritten. Resetting the hidden gauge to zero each time the highest threshold is crossed, ensures the behaviour that a capacity alarm will be generated every time the same fraction of the log capacity is written to the log, and therefore the same safety factor is maintained. In other words, every time a fixed percentage of the log capacity is written to the wrapping log, a capacity alarm is emitted. " A draft corrigenda item to X.735 will be progressed to add the above clarifying note. Sender: spruce@ovdm40.cnd.hp.com Date: Fri, 09 Jul 1999 11:18:18 -0600 From: Stephen Spruce Organization: Communications Management Division X-Mailer: Mozilla 4.08 [en] (X11; I; HP-UX B.10.20 9000/777) To: "Matthews, David L, NCIO" CC: "'log_service-ftf@omg.org'" , "'terutt@lucent.com'" Subject: Re: PROPOSED NEW RESOLUTION FOT ISSUE 2754 Hi all, Using ITUs X.735 behavior of wrapping, what happens to the hidden gauge value when records are removed from the log? Suppose I have a log that has a maxsize of 10K and its log full behavior is set to "wrap". I set capacity thresholds at 50%, 90%, and 100%. Operation Capacity Status Gauge Alarm Generated --------- -------- ------- ----- --------------- Start log 0% OK 0 None Write 5K 50% OK 50 Alarm for 50% Write 4K 90% OK 90 Alarm for 90% Write 1K 100% Full 100->0 Alarm for 100% Write 2K 100% Full 20 None Write 3K 100% Full 50 Alarm for 50% Write 4K 100% Full 90 Alarm for 90% Write 1K 100% Full 100->0 Alarm for 100% Remove 7K 30% OK 0(?) None Write 2K 50% OK 20 None Write 3K 80% OK 50 Alarm for 50% Write 1K 90% OK 60 None Write 1K 100% Full 70 None Write 2K 100% Full 90 Alarm for 90% Write 1K 100% Full 100->0 Alarm for 100% As you can see, after removing some records the Alarm generated does not reflect the actual capacity of the log. It does not get any better if we subtract the amount removed from the gauge. An example is if the log is at 100% capacity and the guage is at 20 (Line 5 in table), the what happens when 5K is removed? Does the guage go down to -30? If I understand what ITU is saying, the Gauge is to keep track of the amount of writes since the last Guage reset (either because the log was started empty or the log has wrapped) as opposed to the actual capacity of the log. So if 30 1K inserts are done, alarms will only be generated after 5K, 9K, 10K (reset gauge), 15K, 19K, 20K (reset gauge), 25K, 29K, and 30K? Have I got things totally confused? Can someone give me a working example of how the log capacity is related with the gauge and when alarms will be generated? regards, stephen Matthews, David L, NCIO wrote: > > This mail is being sent for Tom Rutt. Please rely to whole list or to Tom > directly. > Mail from Tom follows: > > The OMG proposed issue resolutions for the Telecom Log RTF were > discussed by the X.700 series meeting.. It was realized that > only two of the OMG Logging Service issues were relevant for > X.735 (issues 2753 and 2754). > > The group agreed with the proposed resolution of Issue 2753, and > agreed to progress a draft corrigenda item for X.735 which makes > the same correction as the proposed resolution of issue 2753. > This corrigenda is needed to clarify that the availability status > has the value "log-full" while under a wrap condition. > > The OMG proposed resolution for issue 2754 was not agreed to. > After discussion which included the original editor of X.735, it > was verified that the original text in X.735 (which was copied > into the OMG Log function) is correct, (i.e., while under wrap > condition, the underlying gauge should be reset to zero whenever > the highest capacity threshold is crossed). The reason for the > reset is to maintain a fixed safety factor to avoid overwriting > log records without an announcement that the overwriting is about > to occur. > > However, it was suggested that the following clarifying note be > added under the existing text on wrap gauge reset. > " > Note: A wrapping log can be viewed as a circular buffer. The > margin between the highest capacity alarm threshold and 100% > can be regarded as a safety factor, to allow sufficient time > for log users to retrieve log records upon receipt of a > capacity alarm, before those records which entered the log > after the previous capacity alarm are overwritten. Resetting > the hidden gauge to zero each time the highest threshold is > crossed, ensures the behaviour that a capacity alarm will be > generated every time the same fraction of the log capacity is > written to the log, and therefore the same safety factor is > maintained. In other words, every time a fixed percentage > of the log capacity is written to the wrapping log, a capacity > alarm is emitted. > " > > A draft corrigenda item to X.735 will be progressed to add the > above clarifying note. -- Stephen H. Spruce Jr. Communication Management Division Hewlett-Packard Co. Ft. Collins, CO (970) 898-7497 spruce@fc.hp.com Date: Mon, 12 Jul 1999 13:29:15 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: "'log_service-ftf@omg.org'" Subject: Re: PROPOSED NEW RESOLUTION FOT ISSUE 2754 Hello, I am back from the ITU-T meeting in Athens. It is important to note that the original editor of X.735 explained why the threshold text is the way it is for wrapping logs. Wrapping logs are intended to behave as circular buffers. The capacity alarm for a wrapping log is meant to be a trigger for users to read its contents, before they are overwritten again. The attached text suggests a note to be added. I think it is important to change the proposed resolution for the last issue. Tom Rutt Matthews, David L, NCIO wrote: > > This mail is being sent for Tom Rutt. Please rely to whole list or to Tom > directly. > Mail from Tom follows: > > The OMG proposed issue resolutions for the Telecom Log RTF were > discussed by the X.700 series meeting.. It was realized that > only two of the OMG Logging Service issues were relevant for > X.735 (issues 2753 and 2754). > > The group agreed with the proposed resolution of Issue 2753, and > agreed to progress a draft corrigenda item for X.735 which makes > the same correction as the proposed resolution of issue 2753. > This corrigenda is needed to clarify that the availability status > has the value "log-full" while under a wrap condition. > > The OMG proposed resolution for issue 2754 was not agreed to. > After discussion which included the original editor of X.735, it > was verified that the original text in X.735 (which was copied > into the OMG Log function) is correct, (i.e., while under wrap > condition, the underlying gauge should be reset to zero whenever > the highest capacity threshold is crossed). The reason for the > reset is to maintain a fixed safety factor to avoid overwriting > log records without an announcement that the overwriting is about > to occur. > > However, it was suggested that the following clarifying note be > added under the existing text on wrap gauge reset. > " > Note: A wrapping log can be viewed as a circular buffer. The > margin between the highest capacity alarm threshold and 100% > can be regarded as a safety factor, to allow sufficient time > for log users to retrieve log records upon receipt of a > capacity alarm, before those records which entered the log > after the previous capacity alarm are overwritten. Resetting > the hidden gauge to zero each time the highest threshold is > crossed, ensures the behaviour that a capacity alarm will be > generated every time the same fraction of the log capacity is > written to the log, and therefore the same safety factor is > maintained. In other words, every time a fixed percentage > of the log capacity is written to the wrapping log, a capacity > alarm is emitted. > " > > A draft corrigenda item to X.735 will be progressed to add the > above clarifying note. -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: "Matthews, David L, NCIO" , "'log_service-ftf@omg.org'" Date: Mon, 12 Jul 1999 15:40:37 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Stephen Spruce Original-CC: "Matthews, David L, NCIO" , "'log_service-ftf@omg.org'" Subject: Re: PROPOSED NEW RESOLUTION FOT ISSUE 2754 Stephen Spruce wrote: > > Hi all, > > Using ITUs X.735 behavior of wrapping, what happens to > the hidden gauge value when records are removed from the log? The wrapping log is intended to be such, that you never have to delete records, just read them before they are overwritten. So any rational behaviour on delete would be ok. How about whenever the log becomes "un full" by deleting, the gauge reverts back to the actual percentage of log capacity which is full. It would go back into the circular buffer state after the first time the log reenters the wrap condition. Another approach is to just "subtract" the percentage corresponding to that which was deleted from the log. Either approach could work, we just have to decide. The key is, that wrapping logs are designed to not require deleting records by management action, the overwriting creates a circular buffer if no records are explicitly deldeter > > Suppose I have a log that has a maxsize of 10K and its log full > behavior is set to "wrap". I set capacity thresholds at 50%, 90%, > and 100%. > > Operation Capacity Status Gauge Alarm Generated > --------- -------- ------- ----- --------------- > Start log 0% OK 0 None > Write 5K 50% OK 50 Alarm for 50% > Write 4K 90% OK 90 Alarm for 90% > Write 1K 100% Full 100->0 Alarm for 100% > Write 2K 100% Full 20 None > Write 3K 100% Full 50 Alarm for 50% > Write 4K 100% Full 90 Alarm for 90% > Write 1K 100% Full 100->0 Alarm for 100% > Remove 7K 30% OK 0(?) None > Write 2K 50% OK 20 None > Write 3K 80% OK 50 Alarm for 50% > Write 1K 90% OK 60 None > Write 1K 100% Full 70 None > Write 2K 100% Full 90 Alarm for 90% > Write 1K 100% Full 100->0 Alarm for 100% > > As you can see, after removing some records the Alarm generated > does not reflect the actual capacity of the log. It does not > get any better if we subtract the amount removed from the gauge. > An example is if the log is at 100% capacity and the guage > is at 20 (Line 5 in table), the what happens when 5K is removed? > Does the guage go down to -30? > > If I understand what ITU is saying, the Gauge is to keep track > of the amount of writes since the last Guage reset (either because > the log was started empty or the log has wrapped) as opposed to > the actual capacity of the log. So if 30 1K inserts are done, > alarms will only be generated after 5K, 9K, 10K (reset gauge), > 15K, 19K, 20K (reset gauge), 25K, 29K, and 30K? > > Have I got things totally confused? Can someone give me a working > example of how the log capacity is related with the gauge and > when alarms will be generated? > > regards, > stephen > > Matthews, David L, NCIO wrote: > > > > This mail is being sent for Tom Rutt. Please rely to whole list or to Tom > > directly. > > Mail from Tom follows: > > > > The OMG proposed issue resolutions for the Telecom Log RTF were > > discussed by the X.700 series meeting.. It was realized that > > only two of the OMG Logging Service issues were relevant for > > X.735 (issues 2753 and 2754). > > > > The group agreed with the proposed resolution of Issue 2753, and > > agreed to progress a draft corrigenda item for X.735 which makes > > the same correction as the proposed resolution of issue 2753. > > This corrigenda is needed to clarify that the availability status > > has the value "log-full" while under a wrap condition. > > > > The OMG proposed resolution for issue 2754 was not agreed to. > > After discussion which included the original editor of X.735, it > > was verified that the original text in X.735 (which was copied > > into the OMG Log function) is correct, (i.e., while under wrap > > condition, the underlying gauge should be reset to zero whenever > > the highest capacity threshold is crossed). The reason for the > > reset is to maintain a fixed safety factor to avoid overwriting > > log records without an announcement that the overwriting is about > > to occur. > > > > However, it was suggested that the following clarifying note be > > added under the existing text on wrap gauge reset. > > " > > Note: A wrapping log can be viewed as a circular buffer. The > > margin between the highest capacity alarm threshold and 100% > > can be regarded as a safety factor, to allow sufficient time > > for log users to retrieve log records upon receipt of a > > capacity alarm, before those records which entered the log > > after the previous capacity alarm are overwritten. Resetting > > the hidden gauge to zero each time the highest threshold is > > crossed, ensures the behaviour that a capacity alarm will be > > generated every time the same fraction of the log capacity is > > written to the log, and therefore the same safety factor is > > maintained. In other words, every time a fixed percentage > > of the log capacity is written to the wrapping log, a capacity > > alarm is emitted. > > " > > > > A draft corrigenda item to X.735 will be progressed to add the > > above clarifying note. > > -- > Stephen H. Spruce Jr. > Communication Management Division > Hewlett-Packard Co. > Ft. Collins, CO > (970) 898-7497 > spruce@fc.hp.com -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Cc: "Matthews, David L, NCIO" , "'log_service-ftf@omg.org'" Date: Mon, 12 Jul 1999 16:58:45 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Stephen Spruce Original-CC: "Matthews, David L, NCIO" , "'log_service-ftf@omg.org'" Subject: Re: PROPOSED NEW RESOLUTION FOT ISSUE 2754 Stephen Spruce wrote: > > Hi all, > > Using ITUs X.735 behavior of wrapping, what happens to > the hidden gauge value when records are removed from the log? Upon further reflection, and speaking with Dave Matthews, it might be best to have the deletion not affect the hidden gauge at all. That is, keep the behaviour simple, the hidden gauge responds only to written records, and is impervious to deleted records. Remember, the wrap log is meant to be a circular buffer. Thus the text should clarify that a wrap log (whether full or not) has its gauge behaving as stated in the current text. > > Suppose I have a log that has a maxsize of 10K and its log full > behavior is set to "wrap". I set capacity thresholds at 50%, 90%, > and 100%. > > Operation Capacity Status Gauge Alarm Generated > --------- -------- ------- ----- --------------- > Start log 0% OK 0 None > Write 5K 50% OK 50 Alarm for 50% > Write 4K 90% OK 90 Alarm for 90% > Write 1K 100% Full 100->0 Alarm for 100% > Write 2K 100% Full 20 None > Write 3K 100% Full 50 Alarm for 50% > Write 4K 100% Full 90 Alarm for 90% > Write 1K 100% Full 100->0 Alarm for 100% > Remove 7K 30% OK 0(?) None > Write 2K 50% OK 20 None > Write 3K 80% OK 50 Alarm for 50% > Write 1K 90% OK 60 None > Write 1K 100% Full 70 None > Write 2K 100% Full 90 Alarm for 90% > Write 1K 100% Full 100->0 Alarm for 100% > > As you can see, after removing some records the Alarm generated > does not reflect the actual capacity of the log. It does not > get any better if we subtract the amount removed from the gauge. > An example is if the log is at 100% capacity and the guage > is at 20 (Line 5 in table), the what happens when 5K is removed? > Does the guage go down to -30? > > If I understand what ITU is saying, the Gauge is to keep track > of the amount of writes since the last Guage reset (either because > the log was started empty or the log has wrapped) as opposed to > the actual capacity of the log. So if 30 1K inserts are done, > alarms will only be generated after 5K, 9K, 10K (reset gauge), > 15K, 19K, 20K (reset gauge), 25K, 29K, and 30K? > > Have I got things totally confused? Can someone give me a working > example of how the log capacity is related with the gauge and > when alarms will be generated? > > regards, > stephen > > Matthews, David L, NCIO wrote: > > > > This mail is being sent for Tom Rutt. Please rely to whole list or to Tom > > directly. > > Mail from Tom follows: > > > > The OMG proposed issue resolutions for the Telecom Log RTF were > > discussed by the X.700 series meeting.. It was realized that > > only two of the OMG Logging Service issues were relevant for > > X.735 (issues 2753 and 2754). > > > > The group agreed with the proposed resolution of Issue 2753, and > > agreed to progress a draft corrigenda item for X.735 which makes > > the same correction as the proposed resolution of issue 2753. > > This corrigenda is needed to clarify that the availability status > > has the value "log-full" while under a wrap condition. > > > > The OMG proposed resolution for issue 2754 was not agreed to. > > After discussion which included the original editor of X.735, it > > was verified that the original text in X.735 (which was copied > > into the OMG Log function) is correct, (i.e., while under wrap > > condition, the underlying gauge should be reset to zero whenever > > the highest capacity threshold is crossed). The reason for the > > reset is to maintain a fixed safety factor to avoid overwriting > > log records without an announcement that the overwriting is about > > to occur. > > > > However, it was suggested that the following clarifying note be > > added under the existing text on wrap gauge reset. > > " > > Note: A wrapping log can be viewed as a circular buffer. The > > margin between the highest capacity alarm threshold and 100% > > can be regarded as a safety factor, to allow sufficient time > > for log users to retrieve log records upon receipt of a > > capacity alarm, before those records which entered the log > > after the previous capacity alarm are overwritten. Resetting > > the hidden gauge to zero each time the highest threshold is > > crossed, ensures the behaviour that a capacity alarm will be > > generated every time the same fraction of the log capacity is > > written to the log, and therefore the same safety factor is > > maintained. In other words, every time a fixed percentage > > of the log capacity is written to the wrapping log, a capacity > > alarm is emitted. > > " > > > > A draft corrigenda item to X.735 will be progressed to add the > > above clarifying note. > > -- > Stephen H. Spruce Jr. > Communication Management Division > Hewlett-Packard Co. > Ft. Collins, CO > (970) 898-7497 > spruce@fc.hp.com -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Date: Tue, 13 Jul 1999 09:54:20 +1000 (EST) From: Michi Henning To: Tom Rutt cc: "'log_service-ftf@omg.org'" Subject: Re: PROPOSED NEW RESOLUTION FOT ISSUE 2754 Organization: Triodia Technologies On Mon, 12 Jul 1999, Tom Rutt wrote: > The capacity alarm for a wrapping log is meant to be a trigger > for users to read its contents, before they are overwritten again. > > The attached text suggests a note to be added. > > I think it is important to change the proposed resolution for > the last issue. It would be nice if someone could answer Stephen's question though. I'm still confused as to the precise semantics of this idea. I get the feeling that the threshold alarms on wrapping logs are an idea that someone came up with but that wasn't tested in practice? Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Tue, 13 Jul 1999 09:57:07 +1000 (EST) From: Michi Henning To: Tom Rutt cc: Stephen Spruce , "Matthews, David L, NCIO" , "'log_service-ftf@omg.org'" Subject: Re: PROPOSED NEW RESOLUTION FOT ISSUE 2754 Organization: Triodia Technologies On Mon, 12 Jul 1999, Tom Rutt wrote: > The wrapping log is intended to be such, that you never have > to delete records, just read them before they are overwritten. > > So any rational behaviour on delete would be ok. > > How about whenever the log becomes "un full" by deleting, the > gauge reverts back to the actual percentage of log capacity > which is full. It would go back into the circular buffer state > after the first time the log reenters the wrap condition. This sounds sensible to me. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Tue, 13 Jul 1999 10:00:22 +1000 (EST) From: Michi Henning To: Tom Rutt cc: Stephen Spruce , "Matthews, David L, NCIO" , "'log_service-ftf@omg.org'" Subject: Re: PROPOSED NEW RESOLUTION FOT ISSUE 2754 Organization: Triodia Technologies On Mon, 12 Jul 1999, Tom Rutt wrote: > Upon further reflection, and speaking with Dave Matthews, it might > be best to have the deletion not affect the hidden gauge at all. > > That is, keep the behaviour simple, the hidden gauge responds > only to written records, and is impervious to deleted records. Huh? In that case, the gauge would go from 0% to 10% to ... to 100% to 0% as the log wraps. If I have a log that is 80% full and delete all records, then, with what you suggest, the gauge would stay at 80% and would got to 100% when another 20% of records are written. This strikes me as totally meaningless and confusing behavior. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Cc: Stephen Spruce , "Matthews, David L, NCIO" , "'log_service-ftf@omg.org'" Date: Tue, 13 Jul 1999 13:14:07 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.06 [en]C-EMS-1.4 (Win95; U) To: Michi Henning Original-CC: Stephen Spruce , "Matthews, David L, NCIO" , "'log_service-ftf@omg.org'" Subject: Re: PROPOSED NEW RESOLUTION FOT ISSUE 2754 Michi Henning wrote: > > On Mon, 12 Jul 1999, Tom Rutt wrote: > > > Upon further reflection, and speaking with Dave Matthews, it might > > be best to have the deletion not affect the hidden gauge at all. > > > > That is, keep the behaviour simple, the hidden gauge responds > > only to written records, and is impervious to deleted records. > > Huh? In that case, the gauge would go from 0% to 10% to ... to 100% to 0% > as the log wraps. If I have a log that is 80% full and delete all records, > then, with what you suggest, the gauge would stay at 80% and would got > to 100% when another 20% of records are written. This strikes me as > totally meaningless and confusing behavior. The gauge in a wrap log with capacity threshold is merely a counter of percent of capacity written to the log. The highest capacity threshold t, establishes a safety factor (100-t), enabling enough time to read the records of the log before they are overwritten. The alarm is a signal for users to read the records of the log before they are overwritten. NOw if a user happens to delete records, there is no logical beginning or end of the "circular buffer" anymore. The physical beginning of the log has no specific bearing on recency of the records. The simple way to define the behavior, is that if a user deletes records from a wrap log, the affect on the threshold mechanism is none. It keeps on counting the percent of capacity as it is written to the circular buffer, and sends an alarm every time it crosses the highest threshold, then resets to zero to resume counting capacity consumption of incoming records. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3236 1633 > Triodia Technologies +61 4 1118 2700 (mobile) > PO Box 372 +61 7 3211 0047 (fax) > Annerley 4103 michi@triodia.com > AUSTRALIA http://www.triodia.com/staff/michi-henning.html -- Tom Rutt email: terutt@lucent.com Lucent Technologies Bell Labs Tel: +1(732)949-7862 Rm 4L-336 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA Date: Wed, 14 Jul 1999 06:15:26 +1000 (EST) From: Michi Henning To: Tom Rutt cc: Stephen Spruce , "Matthews, David L, NCIO" , "'log_service-ftf@omg.org'" Subject: Re: PROPOSED NEW RESOLUTION FOT ISSUE 2754 Organization: Triodia Technologies On Tue, 13 Jul 1999, Tom Rutt wrote: > The simple way to define the behavior, is that if a user deletes > records from a wrap log, the affect on the threshold mechanism > is none. It keeps on counting the percent of capacity as it is > written to the circular buffer, and sends an alarm every time it > crosses the highest threshold, then resets to zero to resume counting > capacity consumption of incoming records. OK, I understand. However, this also means that I can get a 90% full alarm, then delete all 90% and a few seconds later get a 95% full alarm. To me, it would be far more logical to reset the gauge to the actual percentage of the log when deleting records. That way, at least I don't get surprising alarms. In terms of implementation difficulty, I would think that's not that much more complex. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html