Issue 4338: event channel buffer should generate exception when buffer beg. to overflow (event-rtf) Source: Union Switch & Signal (Mr. William A. Visnich, wavisnich(at)switch.com) Nature: Uncategorized Issue Severity: Summary: The Event Service spec should be revised to include a mandatory throwing of an exception if an Event Channel buffer begins to overflow. This exception should be able to be caught by both the server and client applications. The reason is that without an exception, the Event Service is making a implicit comment on the value of an individual message. Although the Event Service paradigm is publish/subscribe, there may be uses within that context when the dropping of a single message is critical. Without implementing traditional message tracking solutions such as the sequencing messages, there is currently no way of knowing if a message has been dropped. The throwing of an exception that can be caught, or not caught, seems to be a reasonable solution. It would also increase the value of the services currently provided by the Event Service. Resolution: Revised Text: Actions taken: June 5, 2001: received issue Discussion: End of Annotations:===== Date: Tue, 05 Jun 2001 12:45:48 -0400 From: "Visnich, William A" Subject: Event Service - event channel buffer should generate an exceptio n when the buffer begins to overflow To: "'issues@omg.org'" Cc: "'Juergen Boldt'" Message-id: <8F329FEDF58BD411BE5200508B10DA7673273F@exchptc1.switch.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-UIDL: K,/e9j;&!!k`C!!4$-!! The Event Service spec should be revised to include a mandatory throwing of an exception if an Event Channel buffer begins to overflow. This exception should be able to be caught by both the server and client applications. The reason is that without an exception, the Event Service is making a implicit comment on the value of an individual message. Although the Event Service paradigm is publish/subscribe, there may be uses within that context when the dropping of a single message is critical. Without implementing traditional message tracking solutions such as the sequencing messages, there is currently no way of knowing if a message has been dropped. The throwing of an exception that can be caught, or not caught, seems to be a reasonable solution. It would also increase the value of the services currently provided by the Event Service. Date: Wed, 6 Jun 2001 11:08:24 +1000 (EST) From: Michi Henning To: event-rtf@emerald.omg.org cc: wavisnich@switch.com Subject: Re: issue 4338 -- Event RTF issue (to be re-chartered?) In-Reply-To: <4.3.2.7.2.20010605131208.04b94ca0@emerald.omg.org> Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Z&`!!-md!!LVg!!IB]!! On Tue, 5 Jun 2001, Juergen Boldt wrote: > This is issue # 4338 > > event channel buffer should generate exception when buffer begins to > overflow > > The Event Service spec should be revised to include a mandatory > throwing of > an exception if an Event Channel buffer begins to overflow. This > exception > should be able to be caught by both the server and client > applications. The > reason is that without an exception, the Event Service is making a > implicit > comment on the value of an individual message. Although the Event > Service > paradigm is publish/subscribe, there may be uses within that context > when > the dropping of a single message is critical. Without implementing > traditional message tracking solutions such as the sequencing > messages, > there is currently no way of knowing if a message has been dropped. > The > throwing of an exception that can be caught, or not caught, seems to > be a > reasonable solution. It would also increase the value of the > services > currently provided by the Event Service. Sorry, but that suggestion is unimplementable: 1) The fundamental model of the event service is one of decoupled communication. This means that suppliers are shielded from misbehavior by other suppliers and consumers, and consumers are shielded from misbehavior by other consumers and suppliers. 2) Sending an exception back to the supplier if an event channel cannot buffer a new event would make the supplier aware of the state of the downstream consumers. In particular, the supplier would become aware of whether there is a slow consumer, or no consumer at all, which violates the basic model. 3) If channels are federated, with one channel feeding into another, the requirement cannot be implemented unless delivery of events would be done synchronously to the down-stream channel (because, otherwise, the upstream channel accepting the event could not inform the supplier that the downstream channel cannot buffer the event), but synchronous delivery of events would violate the basic model. 4) A channel has no idea whether is supplies events to another channel or an application consumer, and a supplier has no idea whether it supplies events to a channel, federated channels, or directly to the consumer. It follows that, if the requirement to raise an exception on failure to buffer an event were implemented, supplying an event would have to block the supplier until that event has been delivered to *all* consumers *anywhere* in a federation, which violates the basic model. 5) Notification of failure to successfully buffer an event doesn't achieve anything because success in buffering an event doesn't mean that the event won't be lost later. In other words, not getting the suggested exception on a particular call would not give me any better guarantees as I get now, with no such exception at all. The raw fact of life is that, if I want reliable delivery of events (or even notification of whether the event was successfully buffered), I have to either layer an application level protocol over the event service, using sequence numbers to detect dropped events and request retransmission somehow, or I don't use the event service at all and communicate via reliable two-way calls. I can't have it every which way: reliable delivery (or notification of dropped events), federation, decoupled communication, and asynchronous delivery. Something has to give somewhere -- not knowing when events are dropped is what gives in the event service, by definition. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi