Issue 1580: We need default value for DiscardPolicy (notif_service-rtf) Source: (, ) Nature: Revision Severity: Summary: Summary: In the spec we define the DiscardPolicy QoS property, and the various settings it can take on. But, we don"t define what the behavior is when the property is not set, and we don"t define a value of NONE that can be used to disable the DiscardPolicy after it has been set. My proposal is to define a new value, say NoOrder, which is the default value and means that DiscardPolicy is disabled, so attempts to send events to the channel when the buffer is full will fail, rather than have events already in the buffer be discarded. As a related issue, we may also want to define a DiscardInterval, so that if DiscardPolicy does kick in, the algorithm can select more than one event from the buffer to discard. This would prevent the channel from thrashing between executing its discard algorithm, and receiving new events. I"d be interested in comments about this idea, in addition to the proposal to define the NoOrder value for DiscardPolicy. Resolution: Revised Text: Actions taken: June 25, 1998: received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: From: "Michael J. Greenberg" Subject: New issue...need default value for DiscardPolicy... To: notif_service-rtf@omg.org Date: Wed, 24 Jun 1998 22:00:55 -0400 (EDT) Cc: juergen@omg.org Hello, I would like to open a new issue for the Notification Service RTF to consider. In the spec we define the DiscardPolicy QoS property, and the various settings it can take on. But, we don't define what the behavior is when the property is not set, and we don't define a value of NONE that can be used to disable the DiscardPolicy after it has been set. Basically, the intent behind DiscardPolicy is to enable the administrator of the channel to modify the channel's behavior when attempts are made to supply events to it, and it's internal buffer is full (i.e., MaxQueueLength messages are waiting to be delivered). I think the intent is also that the default behavior is such that if DiscardPolicy has not been sent, attempts to send events to the channel should fail with a system exception (IMP_LIMIT). In addition, it should be possible to unset DiscardPolicy if it has been previously set. Currently, the following are defined as possible values that DiscardPolicy can take on: const short AnyOrder = 0; const short FifoOrder = 1; const short PriorityOrder = 2; const short DeadlineOrder = 3; const short LifoOrder = 4; My proposal is to define a new value, say NoOrder, which is the default value and means that DiscardPolicy is disabled, so attempts to send events to the channel when the buffer is full will fail, rather than have events already in the buffer be discarded. As a related issue, we may also want to define a DiscardInterval, so that if DiscardPolicy does kick in, the algorithm can select more than one event from the buffer to discard. This would prevent the channel from thrashing between executing its discard algorithm, and receiving new events. I'd be interested in comments about this idea, in addition to the proposal to define the NoOrder value for DiscardPolicy. Regards, Mike -- Michael J. Greenberg NEC Systems Lab. 4 Independence Way Tel. 609-734-6142 Princeton, NJ 08540 Fax. 609-734-6001 mjg@syl.nj.nec.com Return-Path: Date: Thu, 25 Jun 1998 11:39:10 -0400 From: Kevin Currey To: mjg@syl.nj.nec.com Cc: notif_service-rtf@omg.org, juergen@omg.org Subject: Re: New issue...need default value for DiscardPolicy... Reply-To: currey_k@che.hp.com > Currently, the following are defined as possible values that DiscardPolicy > can take on: > > const short AnyOrder = 0; > const short FifoOrder = 1; > const short PriorityOrder = 2; > const short DeadlineOrder = 3; > const short LifoOrder = 4; > > My proposal is to define a new value, say NoOrder, which is the default > value and means that DiscardPolicy is disabled, so attempts to send events > to the channel when the buffer is full will fail, rather than have events > already in the buffer be discarded. I think adding this option is a good idea since it is a valid response to a buffer being full. However, I'm not convinced that NoOrder should be the default behavior. Perhaps some of the other options can be considered for the default value as well. -- Kevin W. Currey http://heart.che.hp.com/~currey_k OpenView Telecom ORB Plus Team currey_k@che.hp.com Hewlett-Packard Company 300 Apollo Drive; Chelmsford, MA 01824 USA phone: +1 978 436-5923 telnet: +1 436-5923 fax: +1 978 436-5176 Return-Path: To: notif_service-rtf@omg.org cc: issues@omg.org Subject: Re: New issue...need default value for DiscardPolicy... Date: Fri, 26 Jun 1998 14:45:25 +1000 From: Keith Duddy Hi Mike, >I think the intent is also that the default behavior is such that if >DiscardPolicy has not been sent, attempts to send events to the channel >should fail with a system exception (IMP_LIMIT). In addition, it should >be possible to unset DiscardPolicy if it has been previously set. If we're going to have a new (default) value of this QoS param, then I'd rather not talk about "unsetting" the value. The DiscardPolicy is always active, and always has a value - it's just that if the user/admin doesn't explicitly set it, then its value is the default. (I take your point that the user/admin may want to set it back to the default after it having some other value - I'm just being careful about the language used to describe that.) >Currently, the following are defined as possible values that DiscardPolicy >can take on: > > const short AnyOrder = 0; > const short FifoOrder = 1; > const short PriorityOrder = 2; > const short DeadlineOrder = 3; > const short LifoOrder = 4; > >My proposal is to define a new value, say NoOrder, which is the default >value and means that DiscardPolicy is disabled, so attempts to send events >to the channel when the buffer is full will fail, rather than have events >already in the buffer be discarded. I'd rather call it RejectNewEvents than NoOrder (which could easily be confused with AnyOrder). But other than that I think you have it right. >As a related issue, we may also want to define a DiscardInterval, so that >if DiscardPolicy does kick in, the algorithm can select more than one >event from the buffer to discard. This would prevent the channel from >thrashing between executing its discard algorithm, and receiving new events. >I'd be interested in comments about this idea, in addition to the proposal >to define the NoOrder value for DiscardPolicy. I'd be wary about this one - adding more timing policies makes the implementation more and more difficult. It's the implementation's job to avoid thrashing, but allowing an administrator to set timing on discards will have unpredictable performance impacts. I'd rather add some text that explicitly allows more than one event to be discarded at the discretion of the implementation - as long as it uses the DiscardPolicy to choose which one(s) to discard. regards, K - -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy :: dud@dstc.edu.au :: http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) Gehrmann Labs, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: From: "Michael J. Greenberg" Subject: Re: New issue...need default value for DiscardPolicy... To: dud@dstc.edu.au (Keith Duddy) Date: Fri, 26 Jun 1998 09:09:29 -0400 (EDT) Cc: notif_service-rtf@omg.org, issues@omg.org, dsm@syl.nj.nec.com Hi Keith, >>If we're going to have a new (default) value of this QoS param, then >>I'd rather not talk about "unsetting" the value. The DiscardPolicy is >>always active, and always has a value - it's just that if the >>user/admin doesn't explicitly set it, then its value is the default. >>(I take your point that the user/admin may want to set it back to the >>default after it having some other value - I'm just being careful >>about the language used to describe that.) Basically, this is what I meant. Without defining this default value for DiscardPolicy, there was no way for the administrator to turn it off after setting it. I didn't really mean we should support a new operation to "unset" the property...just that there should be a value to denote that the default policy is back in affect. So, I'm in complete agreement with you here. >>I'd rather call it RejectNewEvents than NoOrder (which could easily be >>confused with AnyOrder). But other than that I think you have it >>right. I like RejectNewEvents better than NoOrder too. I'm bad at thinking about good names for these things...sorry! >>>As a related issue, we may also want to define a DiscardInterval, so that >>>if DiscardPolicy does kick in, the algorithm can select more than one >>>event from the buffer to discard. This would prevent the channel from >>>thrashing between executing its discard algorithm, and receiving new events. >>>I'd be interested in comments about this idea, in addition to the proposal >>>to define the NoOrder value for DiscardPolicy. >> >>I'd be wary about this one - adding more timing policies makes the >>implementation more and more difficult. It's the implementation's job >>to avoid thrashing, but allowing an administrator to set timing on >>discards will have unpredictable performance impacts. I'd rather add >>some text that explicitly allows more than one event to be discarded >>at the discretion of the implementation - as long as it uses the >>DiscardPolicy to choose which one(s) to discard. Okay. I don't that strongly about this one, it was just a thought. Thanks, Mike -- Michael J. Greenberg NEC Systems Lab. 4 Independence Way Tel. 609-734-6142 Princeton, NJ 08540 Fax. 609-734-6001 mjg@syl.nj.nec.com