Issue 4651: pull request/destroy request issue (event-rtf) Source: (, ) Nature: Clarification Severity: Critical Summary: The event service specification states: "The pull operation blocks until the event data is available or an exception is raised." If there are pull requests pending (because no data is available) and a destroy request is issued, do the pull requests have to return with a "Disconnected" exception ? Remember (p. 2-9): The destroy request should destroy all admin and proxy objects associated, so the proxies being pulled might not be active any more. Testing some notification implementations (e.g. OpenOrb, OpenFusion and dCon) showed that none of them returned from pull request in reasonable time: http://asi28.informatik.uni-hamburg.de/test/Hanging_Pull.java If the pull requests are not supposed to return with an exception, what is the intended way to abort the requests, so that channel and client resources can be reclaimed ? Resolution: Revised Text: Actions taken: October 30, 2001: received issue Discussion: End of Annotations:===== rom: webmaster@omg.org Message-Id: <200110300941.f9U9fJi04179@emerald.omg.org> Date: 30 Oct 2001 04:45:30 -0500 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: ELAe9K4m!!('k!!ee>!! Name: Ralf Bachmann Company: Univ. Hamburg, FB Informatik, ASI mailFrom: bachmann@informatik.uni-hamburg.de Notification: Yes Specification: Event Service Specification Section: 2.1.3 FormalNumber: formal/2001-03-01 Version: 1.1 RevisionDate: 01/03/2001 Page: 2-3 Nature: Clarification Severity: Critical HTTP User Agent: Mozilla/4.78 [en] (X11; U; SunOS 5.8 sun4u) Description The event service specification states: "The pull operation blocks until the event data is available or an exception is raised." If there are pull requests pending (because no data is available) and a destroy request is issued, do the pull requests have to return with a "Disconnected" exception ? Remember (p. 2-9): The destroy request should destroy all admin and proxy objects associated, so the proxies being pulled might not be active any more. Testing some notification implementations (e.g. OpenOrb, OpenFusion and dCon) showed that none of them returned from pull request in reasonable time: http://asi28.informatik.uni-hamburg.de/test/Hanging_Pull.java If the pull requests are not supposed to return with an exception, what is the intended way to abort the requests, so that channel and client resources can be reclaimed ? Date: Wed, 31 Oct 2001 07:08:12 +1000 (EST) From: Michi Henning To: Juergen Boldt cc: issues@emerald.omg.org, event-rtf@emerald.omg.org Subject: Re: issue 4651 -- Event RTF (to be chartered??) issue In-Reply-To: <4.3.2.7.2.20011030140138.02d1dbc0@emerald.omg.org> Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ,/i!!V>_!!lCn!!H_0e9 On Tue, 30 Oct 2001, Juergen Boldt wrote: > This is issue # 4651 > > pull request/destroy request issue > > The event service specification states: "The pull operation blocks > until > the event data is available or an exception is raised." > > If there are pull requests pending (because no data is available) > and a > destroy request is issued, do the pull requests have to return with > a > "Disconnected" exception ? > > Remember (p. 2-9): The destroy request should destroy all admin and > proxy > objects associated, so the proxies being pulled might not be active > any more. > > Testing some notification implementations (e.g. OpenOrb, OpenFusion > and > dCon) showed that none of them returned from pull request in > reasonable > time: http://asi28.informatik.uni-hamburg.de/test/Hanging_Pull.java > > If the pull requests are not supposed to return with an exception, > what is > the intended way to abort the requests, so that channel and client > resources can be reclaimed ? The spec requires the channel to invoke the corresponding disconnect callback on tall the proxies when the channel is destroyed; the Disconnected exception in the spec is a red herring because it can't possibly be raised. After all, the corresponding proxy is destroyed, so any new push or pull operations invoked on the proxy will raise OBJECT_NOT_EXIST. For a push or pull that is in progress, I would suggest the following: The push will either throw OBJECT_NOT_EXIST or complete normally, depending on whether (logically), the push happened just before or after destruction. For a blocked pull() operation, it can simply raise OBJECT_NOT_EXIST when the proxy is destroyed. 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