Issue 2555: Semantics of Disconnected exception (notif_service-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: It would be nice if the spec explicitly stated what happens when a pull supplier or push consumer raises the Disconnected exception. One way to look at it is that when the client raises Disconnected it no longer wants to send or receive any events and it"s basically disconnected (i.e. the same as if the disconnect_xx_yy operation was invoked). I believe this is an issue because the disconnect_xx_yy operation controls the lifecycle of the proxy. If the above interpretation is valid, the proxy will be destroyed when the client raises Disconnected. Alternatively, the proxy could just change its state back to not connected (the same state as when the proxy was just created by an admin object). Resolution: resolved, see below Revised Text: Added text to end of 1st paragraph in sections 3.3.71., 3.3.9.1, 3.3.9.2, 3.3.11.1, 3.3.13.1, 3.3.13.2 Actions taken: March 29, 1999: received issue November 16, 1999: closed issue Discussion: ynopsis: The spec does not define specifically what happens when an endpoint pull-supplier or push-consumer raises the Disconnected exception. The submitter of the issue mentions one interpretation is that when an endpoint client raises Disconnected, it no longer wants to send/receive events and is basically disconnected. He adds that this is an issue because being disconnected has object lifecycle implications for the proxies that the clients are connected to... essentially being disconnected implies that the proxies no longer exists. So, one possible semantic that could be defined is that the proxy that the client is connected to could invoke its own disconnect_xx_yy operation to force the proxy to be cleaned up. Another possible semantic, however, is that the proxy could change its state back to existing but being not connected, such as it was when it was created and prior to the client connecting. The submitter of the issue goes on to say that it would be useful to specify in what states (i.e., between CONNECTED, NOT_CONNECTED, SUSPENDED, and DESTROYED) event type information is propagated through the NotifyPublish/NotifySubscribe interfaces. Disposition: Regarding the main issue, I feel the issue author's first recommendation is correct...the semantic should be that if an endpoint raises the "Disconnected" exception during a proxy's attempt to send/receive an event, the proxy's disconnect_xx_yy method should be invoked to destroy the proxy. As the issue author pointed out, the intended semantic of Notification is such that when a client disconnects, its proxy should be destroyed. This implies that proxies are not intended to be reused by multiple clients. If the proxy is attempting to perform event transmission to/from its client, then this implies the client had explicitly connected at some point. If the client later on decides it is disconnected, then the proxy should update its state to be consistent. This means that the proxy should be destroyed. And, regarding the second part of the issue, I feel event type information should be propagated to a client when its proxy is in the CONNECTED or SUSPENDED state. Note that a client can turn off event type propagation at any time by invoking the obtain_*_types operation on its proxy with an argument of ALL_NOW_UPDATES_OFF or NONE_NOW_UPDATES_OFF. VOTE: YES means to add text specifying that when a client raises the "Disconnected" exception, its proxy's disconnect_xx_yy method is automatically invoked to destroy the proxy, and to add text that states event type information is propagated to a client in the CONNECTED or SUSPENDED state. NO means to do nothing. End of Annotations:===== Date: Fri, 26 Mar 1999 08:41:41 -0600 From: Bjarne Rasmussen Organization: PrismTech Corp To: issues@omg.org Subject: Notification Service RTF: Semantics of Disconnected exception Hi, It would be nice if the spec explicitly stated what happens when a pull supplier or push consumer raises the Disconnected exception. One way to look at it is that when the client raises Disconnected it no longer wants to send or receive any events and it's basically disconnected (i.e. the same as if the disconnect_xx_yy operation was invoked). I believe this is an issue because the disconnect_xx_yy operation controls the lifecycle of the proxy. If the above interpretation is valid, the proxy will be destroyed when the client raises Disconnected. Alternatively, the proxy could just change its state back to not connected (the same state as when the proxy was just created by an admin object). If the states for a proxy are termed NOT_CONNECTED, CONNECTED, SUSPENDED and DESTROYED, it would also be useful to specify in what states the proxies are expected to publish changes in event type information using the NotifyPublish and NotifySubscribe interfaces. Best regards, Bjarne. -- Bjarne Rasmussen, Senior Software Engineer (M.Sc) PrismTech Limited, http://www.prismtechnologies.com