Issue 2652: Modify the DiscardPolicy text, paragraph 1 page 56 (notif_service-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The description of when and how to apply discard policies is ambiguous. It is unclear whether the discard policy is intended to be applied on the events in their original order or as ordered by an order policy. Resolution: resolved, see below Revised Text: Made several changes to section 2.5.7. Made corresponding changes to Discard Policy section of Section 2.5.5. Made appropriate changes to IDL in Table 3.1 and Table B.1 (removed RejectNewEvents as possible setting of DiscardPolicy, added RejectNewEvents as a possible Admin property). Actions taken: May 18, 1999: received issue November 16, 1999: closed issue Discussion: Synopsis: The issue submitter feels that description of when and how to apply discard policy is ambiguous with respect to whether the policy is intended to be applied on the events in their original order or as ordered by an order policy. The issue submitter proposed the following rewording of paragraph 1 on page 56: "This QoS property enables a user of the Notification Service to specify in what order the channel should begin discarding events in the case of an internal buffer overflow." "If a discard policy is set on a channel, it is applied when the total number of events already queued in the channel is equal to the MaxQueueLength administrative property (defined in section 2.5.7). If set on a per-ConsumerAdmin basis, the discard policy is applied when the number of events queued on behalf of one of the consumers exceeds the MaxEventsPerConsumer QoS property for that consumer. If set on a per-proxy basis, the discard policy is applied whenever the number of events queued on behalf of the connected consumer exceeds the MaxEventsPerConsumer setting for the proxy supplier. In the latter two cases, an event is discarded only with respect to its scheduled delivery to the consumer(s) on whose behalf the policy is being applied. Events queued for delivery to a consumer for which the discard policy does not apply are not affected and remain queued for that consumer." "In all cases, discard policies are applied after the event has been received and queued. The RejectNewEvents discard policy is the only exception as it is applied before the event is queued." In addition, the issue submitter proposed the following rewording for the descriptions of the LifeOrder and FifoOrder discard policy settings: "FifoOrder - The first event in the queue is the first discarded." "LifeOrder - The last event in the queue is the first discarded." The above is the original proposed resolution, and is now considered resolution 2652a. Below are proposed resolutions 2652b and 2652c: First, the background for the new proposed resolution: There are some issues that appear in connection with the DiscardPolicy that are hinted at in the issue (2652) description, but not addressed in the text for the resolution. I think we need to seriously consider amending the resolution to fix these: 1) RejectNewEvents not appropriate at any level other than EventChannel The RejectNewEvents value of DiscardPolicy is now the _default_ value. BUT this value is meaningless at Admin and Proxy levels (I assume that we don't want the behaviour that setting RejectNew on any SupplierProxy results in all ConsumerProxies rejecting push calls (or not making any further pull calls) until the SupplierProxy's queue has space again - and I can't think of any other plausible semantics). Therefore its inheritance as the value for created Admins and Proxies is inappropriate. There are several ways in which this can be fixed: Here are the proposed alternative resolutions. Note that I've relabel them as b) and c), so that the initial proposed resolution can be considered resolution a). b) [Minimal change model] State somewhere that although this value is the default at the Channel, that when Admins and Proxies are created the value that they inherit when RejectNewEvents is set at the Channel will be Any. Note that this is really a quick and dirty fix, as it breaks the QoS inheritance model, and (c) provides a more considered approach. c) [is RejectNew really a DiscardPolicy?] Given that the inheritance of DiscardPolicy to Admins and their Proxies makes sense when its value is set to anything other than RejectNew, it seems that this value is inappropriate for this policy. In fact, because the value applies only at the channel level, it seems that it would be better to have it as a separate property (rather than an "orthogonal value" of an existing property). AND it seems that this property would be better grouped with other properties that apply to the channel as a whole - the Admin Properties. It would be a boolean valued property with the semantics: TRUE: when queue resources for the channel are full, do not discard events - rather suspend all pull calls from Proxy Pull Consumers, and raise a <Name of System Exception> exception to all incoming push calls on Proxy Push Consumers. FALSE: when queue resources for the channel are full apply the Discard Policy to avoid overruns at each appropriate object where there is a queue. With this resolution the Any value for Discard Policy would become the default. Disposition: I personally have no strong feelings about this issue, since we (NEC) feel that DiscardPolicy only makes sense on a per-channel basis anyway. But, I'll go along with option c), since technically it is the most correct. VOTE: Voters can vote YES to at most one of 2652a, 2652b, or 2652c. Voting YES to one of these means that proposed resolution is the one of choice for your company. Voting NO to all 3 is also valid, and means that no change should be made with regard to this issue. NOTE: Only 2652c passed End of Annotations:===== From: "Michael J. Greenberg" Message-Id: <199905132005.QAA26381@syl.syl.nj.nec.com> Subject: Please add these new issues... To: juergen@omg.org Date: Thu, 13 May 1999 16:05:03 -0400 (EDT) Cc: notif_service-rtf@omg.org, issues@omg.org, matthew@ooc.com, be@ooc.com X-Mailer: ELM [version 2.4ME+J0.42 PL39 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: 081793e151fcba5161e79756e993697b Hi Juergen, Would you please add the 4 new issues summarized below to the Notification Service RTF issues list? Thanks, Mike ----- Forwarded message from Brent Eagles ----- From: "Brent Eagles" To: Cc: Subject: Issues for discussion Date: Mon, 22 Mar 1999 14:32:59 -0330 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-UIDL: e018d9eae011485f6d2c02646a8a0b2e Issue: ====== The description of when and how to apply discard policies is ambiguous. It is unclear whether the discard policy is intended to be applied on the events in their original order or as ordered by an order policy. Proposed change: ================ Modify the DiscardPolicy text, paragraph 1 page 56 to read... "This QoS property enables a user of the Notification Service to specify in what order the channel should begin discarding events in the case of an internal buffer overflow." "If a discard policy is set on a channel, it is applied when the total number of events already queued in the channel is equal to the MaxQueueLength administrative property (defined in section 2.5.7). If set on a per-ConsumerAdmin basis, the discard policy is applied when the number of events queued on behalf of one of the consumers connected to one of the proxy suppliers created by the ConsumerAdmin exceeds the MaxEventsPerConsumer for that consumer. If set on a per-proxy basis, the discard policy is applied whenever the number of events queued on behalf of the connected consumer exceeds the MaxEventsPerConsumer setting for the proxy supplier. In the latter two cases, an event is discarded only with respect to its scheduled delivery to the consumer(s) on whose behalf the policy is being applied. Events queued for delivery to a consumer for which the discard policy does not apply are not affected and remain queued for that consumer." "In all cases, discard policies are applied after the event has been received and queued. The RejectNewEvents discard policy is the only exception as it is applied before the event is queued." and the discard policy value descriptions of LifoOrder and FifoOrder to.. "FifoOrder- The first event in the queue is the first discarded." "LifoOrder- The last event in the queue is the first discarded."