Issue 3114: Semantics of Event Service disconnect_push_consumer/supplier() (notif_service-rtf) Source: Motorola (Mr. Tom Ziomek, CTZ001(at)email.mot.com) Nature: Uncategorized Issue Severity: Summary: The question concerns the disconnect_push_consumer() family of operations (push and pull, consumer and supplier) on both the Event Svc side (proxy suppliers and consumers) and application side (suppliers and consumers). 1) Is a proxy's disconnect_..._...() meant to be called by (any or all of) - the corresponding application supplier/consumer? - some other part of the application? - any portion of the Event Svc implementation? If "yes" in this case, is the connected application object also supposed to be invoked, to notify it of the proxy's shutdown? 2) Is an application consumer/supplier's disconnect_..._...() meant to be called by - some other part of the application? If "yes" in this case, is the application consumer/supplier then expected to invoke disconnect_() on the corresponding proxy object? - any portion of the Event Svc implementation? If "yes", under what circumstances? The specific issue at hand presumes the application object's disconnect_() operation is to be invoked by the Event Svc. The question is when -- one opinion is that a call to the proxy's disconnect_() results in the invoca- tion of disconnect_() on the proxy's application object. The opposing o- pinion is that the application object's disconnect_() is invoked only when the application object is being disconnected by some means other than a call to the proxy's disconnect_() (for example, if the event channel's destroy() is called while application objects are still connected). Resolution: Revised Text: Actions taken: November 19, 1999: received issue February 27, 2001: closed issue Discussion: When a channel is destroyed, all its proxies invoke the disconnect callback (if a callback was registered). In addition, calling a disconnect operation on a proxy causes the proxy to make the appropriate disconnect callback. Proxy implementations are responsible for avoiding infinite recursion. See http://cgi.omg.org/pub/notification-rtf/2_modules_draft1.pdf for a version of the original specification that includes the edits for this issue marked with change bars. End of Annotations:===== Date: Fri, 19 Nov 1999 01:28:18 -0600 (CST) From: Tom Ziomek Message-Id: <199911190728.BAA01241@cc792.comm.mot.com> To: issues@omg.org Subject: Semantics of Event Service disconnect_push_consumer/supplier() Cc: coryan@cs.wustl.edu, levine@cs.wustl.edu, michi@ooc.com.au, schmidt@cs.wustl.edu, tomz@cc701.comm.mot.com Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: W=/e9V=Le9SVjd9b&0!! Hello. A question of interpretation has come up in the Event Service, and I would like to receive an authoritative answer regarding what is re- quired for compliant behavior by an Event Svc (as well as what is proper behavior by an application). The question concerns the disconnect_push_consumer() family of operations (push and pull, consumer and supplier) on both the Event Svc side (proxy suppliers and consumers) and application side (suppliers and consumers). 1) Is a proxy's disconnect_..._...() meant to be called by (any or all of) - the corresponding application supplier/consumer? - some other part of the application? - any portion of the Event Svc implementation? If "yes" in this case, is the connected application object also supposed to be invoked, to notify it of the proxy's shutdown? 2) Is an application consumer/supplier's disconnect_..._...() meant to be called by - some other part of the application? If "yes" in this case, is the application consumer/supplier then expected to invoke disconnect_() on the corresponding proxy object? - any portion of the Event Svc implementation? If "yes", under what circumstances? The specific issue at hand presumes the application object's disconnect_() operation is to be invoked by the Event Svc. The question is when -- one opinion is that a call to the proxy's disconnect_() results in the invoca- tion of disconnect_() on the proxy's application object. The opposing o- pinion is that the application object's disconnect_() is invoked only when the application object is being disconnected by some means other than a call to the proxy's disconnect_() (for example, if the event channel's destroy() is called while application objects are still connected). Please feel free to contact me at tomz@comm.mot.com or 847-576-7286 if you need further explanation of my question. Thanks, Tom Ziomek, Motorola Date: Wed, 15 Mar 2000 11:01:30 -0600 From: Bjarne Rasmussen Organization: PrismTech Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: notif-service-rtf@omg.org CC: Paul Moxon , Steve Osselton Subject: Issue 3114 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: No4!!$D'e9Ad?e9K\7!! Hi, In order to resolve this issue, we suggest to provide text for the proxy disconnect operations that reflects that these operations are supported by two different types of objects (in a similar manner to the notification service specification for such operations). First part of this mail is our suggestion, second part is discussion. -- Suggestion: As an example, for the disconnect_push_supplier operation: In reality, there are two types of objects that will support the PushSupplier interface: an object representing an application which transmits un-typed events, and a ProxyPushSupplier (defined within the CosEventChannelAdmin module) associated with an event channel which transmits events to a PushConsumer on behalf of the channel. For the first type of object, the implementation of the disconnect_push_supplier is application specific and is intended to be supplied by application developers. This operation is invoked by the notification service when the destroy operation is invoked on the channel or admin object that the supplier is connected to. other channel admins proxies clients | destroy | | | | |--------------->| destroy | | | | |--------------->| disconnect | | | | |--------------->| disconnect | | | | |--------------->| The disconnect_push_supplier operation is thus a callback which is invoked when the channel or admin has been destroyed by a third party. For the second type of object, the behavior of the operation is tightly linked to the implementation of the event channel. When a client invokes the disconnect_push_supplier operation of a ProxyPushSupplier object, the proxy object is disconnect and destroyed. Any resources held on behalf of the proxy will be released and the proxy object can no longer be used by any client. Subsequent invocations of any operation on the proxy object will raise the OBJECT_NOT_EXIST system exception. -- Discussion: The above suggestion introduces two problems. The first is that a client might not discover if a third-party object disconnects its proxy. This is particularly relevant for pull suppliers and push consumers. A solution could be to always have the proxy do a callback when the disconnect operation of the proxy is invoked: other proxy client | disconnect | | |--------------->| disconnect | | |--------------->| The second problem is that proxies might not discover that a client has been destroyed. This is particularly relevant for proxy pull suppliers and proxy push consumers. However, a difficulty arises when attempting to solve this by having the client call the proxy's disconnect operation whenever the client's disconnect operation is called: other client proxy | disconnect | | |--------------->| disconnect | | |--------------->| | | disconnect | | |<---------------| As can be seen, the client must have logic to prevent it from performing two disconnect calls. We don't think the proxy can detect this because it should raise OBJECT_NOT_EXIST if disconnect is called twice. If the client detects the disconnect, it will be ok for the client to raise OBJECT_NOT_EXIST the second time (proxy would ignore this). Note that this solution triples the number of calls on channel destruction. We believe that a requirement for disconnect detection in the client is undesirable. Whether or not the notification service can detect disconnected clients is an implementation issue that could (should?) be left out of the specification. An implementation of the notification service could for instance provide appropriate timeout QoS properties on the proxy to support this functionality. The first problem does represent an issue, but we feel that there is an implied one to one relationship between a client and its proxy. The client should not expect third-party objects to interact directly with their proxy object. If some application decides to disconnect a third-party proxy, the application should in turn take the appropriate actions to also notify the affected client object. To state this a bit more precisely: a client is more often than not going to disconnect its own proxy. We think this is rarely done by third-party applications. It seems odd that each call to disconnect results in a callback to disconnect. Also, while we used to support exactly this behavior in our product, we changed it because such callbacks are not supported by certain threading models. Best regards, Bjarne. Sender: tomz@cc701.comm.mot.com Message-ID: <38D01465.E1532050@comm.mot.com> Date: Wed, 15 Mar 2000 16:53:25 -0600 From: Tom Z X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: Bjarne Rasmussen CC: notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Subject: Re: Issue 3114 References: <38CFC1EA.F8FF23BB@us.prismtechnologies.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5Zf!!cRH!!]p3!!4R[d9 [In case you're wondering, I submitted this issue] Bjarne Rasmussen wrote: > -- Suggestion: > > As an example, for the disconnect_push_supplier operation: > > In reality, there are two types of objects that will support the > PushSupplier interface: an object representing an application which > transmits un-typed events, and a ProxyPushSupplier (defined within > the > CosEventChannelAdmin module) associated with an event channel which > transmits events to a PushConsumer on behalf of the channel. For the > first type of object, the implementation of the > disconnect_push_supplier > is application specific and is intended to be supplied by > application > developers. This operation is invoked by the notification service > when > the destroy operation is invoked on the channel or admin object that > the > supplier is connected to. I would make a broader statement: The application object implementing PushSupplier (or whatever) should have its disconnect() called any time the channel and/or admin have chosen to destroy or delete the corresponding proxy object. > other channel admins proxies > clients > | destroy | | | > | > |--------------->| destroy | | > | > | |--------------->| disconnect | > | > | | |--------------->| disconnect > | > | | | > |--------------->| > > The disconnect_push_supplier operation is thus a callback which is > invoked when the channel or admin has been destroyed by a third > party. > For the second type of object, the behavior of the operation is > tightly > linked to the implementation of the event channel. When a client > invokes > the disconnect_push_supplier operation of a ProxyPushSupplier > object, > the proxy object is disconnect and destroyed. Any resources held on > behalf of the proxy will be released and the proxy object can no > longer > be used by any client. Subsequent invocations of any operation on > the > proxy object will raise the OBJECT_NOT_EXIST system exception. > > -- Discussion: > > The above suggestion introduces two problems. The first is that a > client > might not discover if a third-party object disconnects its proxy. Yes. >This > is particularly relevant for pull suppliers and push consumers. A > solution could be to always have the proxy do a callback when the > disconnect operation of the proxy is invoked: > > other proxy client > | disconnect | | > |--------------->| disconnect | > | |--------------->| Okay. But from the proxy's perspective this is the same as your 1st dia- gram above. So isn't this behavior already expected? > The second problem is that proxies might not discover that a client has > been destroyed. This is particularly relevant for proxy pull suppliers > and proxy push consumers. However, a difficulty arises when attempting > to solve this by having the client call the proxy's disconnect operation > whenever the client's disconnect operation is called: > > other client proxy > | disconnect | | > |--------------->| disconnect | > | |--------------->| > | | disconnect | > | |<---------------| > > As can be seen, the client must have logic to prevent it from performing > two disconnect calls. We don't think the proxy can detect this because > it should raise OBJECT_NOT_EXIST if disconnect is called twice. If the > client detects the disconnect, it will be ok for the client to raise > OBJECT_NOT_EXIST the second time (proxy would ignore this). Note that > this solution triples the number of calls on channel destruction. > > We believe that a requirement for disconnect detection in the client is > undesirable. Makes sense. Requiring that clients handle OBJECT_NOT_EXIST being thrown from the proxy seems reasonable. They have to do that today anyway. >Whether or not the notification service can detect > disconnected clients is an implementation issue that could (should?) > be > left out of the specification. An implementation of the notification > service could for instance provide appropriate timeout QoS > properties on > the proxy to support this functionality. > > The first problem does represent an issue, but we feel that there is > an > implied one to one relationship between a client and its proxy. I take this to mean a client has only one proxy, and a proxy has only one client. If so, then yes, I agree, and somebody (Michi? I can look it up) has stated as such. It might be good to codify this rather than rely on everyone seeing the same implication. >The > client should not expect third-party objects to interact directly > with > their proxy object. Hmm. This goes beyond the "1-to-1" relationship statement, in my opinion. What happens w/ federated event channels (the nearest example I can find is Henning & Vinoski p. 944; I think Doug Schmidt's tutorial shows the same thing)? When federating, don't we *usually* have a third party per- forming the connect(), and presumably disconnect(), calls? Proxy Proxy Channel A ====> Push ====> Push ====> Channel B Supplier Consumer >If some application decides to disconnect a > third-party proxy, the application should in turn take the > appropriate > actions to also notify the affected client object. > > To state this a bit more precisely: a client is more often than not > going to disconnect its own proxy. We think this is rarely done by > third-party applications. It seems odd that each call to disconnect > results in a callback to disconnect. Also, while we used to support > exactly this behavior in our product, we changed it because such > callbacks are not supported by certain threading models. After thinking through this, I'm not comfortable with prohibiting 3rd party objects from calling a proxy's disconnect(). I propose - A proxy has one client, and a client has one proxy. - When a proxy's disconnect() is called, the proxy shall call the client's disconnect(). - The proxy's disconnect() shall throw OBJECT_NOT_EXIST if called a 2nd time. - When a client's disconnect() is called, the client shall call the pro- xy's disconnect(). - The client shall handle OBJECT_NOT_EXIST exceptions from the proxy's disconnect(), which is no change from today. This way, whenever the proxy or client has their disconnect() called, they call the other's disconnect(). There are call loops but they are bounded. Does this cover all the possibilities? Your point about adding invocations is well taken. The only option I can see to prevent that is to add operations to both the client and proxy (the names are obviously unsuitable): proxy::disconnect() [called from channel or admin objects] proxy::disconnecting() [called from client] client::disconnect() [called from other application objects] client::disconnected() [called from proxy] The 3rd could be removed and left to the application, if we prohibit the application from calling the existing client::disconnect(). The root of the problem is that for both the client and proxy, disconnect() can be called from "their side" (channel or admin for the proxy, applica- tion for the client) or across the application-EventService boundary. We must either provide a way of distinguishing these or tolerate the extra calls. Thoughts? Thanks, Tom Ziomek X-Sender: mjg@necsyl01.nectech.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 15 Mar 2000 13:29:32 -0500 To: Bjarne Rasmussen From: "Michael J. Greenberg" Subject: Re: Issue 3114 Cc: notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: p0$"!&^Wd9)*Nd9K2F!! Hi Bjarne, Thanks for your laying out this issue in such clear, precise terms. We at NEC totally agree with your arguments. In particular, we do not feel that semantics requiring the implementation of the "disconnect" operations supported by Event/Notification Service proxy objects to invoke the "disconnect" operation of their clients should be added to the specification. We agree with your position that in most cases, it is the client itself that invokes "disconnect" on the Proxy, so having the proxy in turn invoke "disconnect" on the client would be extra, unnecessary communication overhead. Furthermore, we feel this semantic would be problematic for single-threaded clients that invoke "disconnect" on their proxy (since having the proxy in turn invoke "disconnect" on the client would cause a deadlock). In summary, NEC completely concurs with Prism's position on this issue. Regards, Mike At 11:01 AM 3/15/00 -0600, Bjarne Rasmussen wrote: >Hi, > >In order to resolve this issue, we suggest to provide text for the proxy >disconnect operations that reflects that these operations are supported >by two different types of objects (in a similar manner to the >notification service specification for such operations). First part of >this mail is our suggestion, second part is discussion. > >-- Suggestion: > >As an example, for the disconnect_push_supplier operation: > >In reality, there are two types of objects that will support the >PushSupplier interface: an object representing an application which >transmits un-typed events, and a ProxyPushSupplier (defined within the >CosEventChannelAdmin module) associated with an event channel which >transmits events to a PushConsumer on behalf of the channel. For the >first type of object, the implementation of the disconnect_push_supplier >is application specific and is intended to be supplied by application >developers. This operation is invoked by the notification service when >the destroy operation is invoked on the channel or admin object that the >supplier is connected to. > >other channel admins proxies >clients > | destroy | | | | > |--------------->| destroy | | | > | |--------------->| disconnect | | > | | |--------------->| disconnect | > | | | |--------------->| > >The disconnect_push_supplier operation is thus a callback which is >invoked when the channel or admin has been destroyed by a third party. >For the second type of object, the behavior of the operation is tightly >linked to the implementation of the event channel. When a client invokes >the disconnect_push_supplier operation of a ProxyPushSupplier object, >the proxy object is disconnect and destroyed. Any resources held on >behalf of the proxy will be released and the proxy object can no longer >be used by any client. Subsequent invocations of any operation on the >proxy object will raise the OBJECT_NOT_EXIST system exception. > >-- Discussion: > >The above suggestion introduces two problems. The first is that a client >might not discover if a third-party object disconnects its proxy. This >is particularly relevant for pull suppliers and push consumers. A >solution could be to always have the proxy do a callback when the >disconnect operation of the proxy is invoked: > >other proxy client > | disconnect | | > |--------------->| disconnect | > | |--------------->| > >The second problem is that proxies might not discover that a client has >been destroyed. This is particularly relevant for proxy pull suppliers >and proxy push consumers. However, a difficulty arises when attempting >to solve this by having the client call the proxy's disconnect operation >whenever the client's disconnect operation is called: > >other client proxy > | disconnect | | > |--------------->| disconnect | > | |--------------->| > | | disconnect | > | |<---------------| > >As can be seen, the client must have logic to prevent it from performing >two disconnect calls. We don't think the proxy can detect this because >it should raise OBJECT_NOT_EXIST if disconnect is called twice. If the >client detects the disconnect, it will be ok for the client to raise >OBJECT_NOT_EXIST the second time (proxy would ignore this). Note that >this solution triples the number of calls on channel destruction. > >We believe that a requirement for disconnect detection in the client is >undesirable. Whether or not the notification service can detect >disconnected clients is an implementation issue that could (should?) be >left out of the specification. An implementation of the notification >service could for instance provide appropriate timeout QoS properties on >the proxy to support this functionality. > >The first problem does represent an issue, but we feel that there is an >implied one to one relationship between a client and its proxy. The >client should not expect third-party objects to interact directly with >their proxy object. If some application decides to disconnect a >third-party proxy, the application should in turn take the appropriate >actions to also notify the affected client object. > >To state this a bit more precisely: a client is more often than not >going to disconnect its own proxy. We think this is rarely done by >third-party applications. It seems odd that each call to disconnect >results in a callback to disconnect. Also, while we used to support >exactly this behavior in our product, we changed it because such >callbacks are not supported by certain threading models. > >Best regards, >Bjarne. > > > > Michael J. Greenberg NEC Systems, Inc. 305 Foster Street Littleton, MA 01460-2004 VOX: (978)-742-8127 FAX: (978)-742-8557 E-mail: mjg@nectech.com Date: Thu, 16 Mar 2000 10:31:04 -0600 From: Bjarne Rasmussen Organization: PrismTech Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tom Z CC: notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Subject: Re: Issue 3114 References: <38CFC1EA.F8FF23BB@us.prismtechnologies.com> <38D01465.E1532050@comm.mot.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 9fI!!#^F!!D(M!!>I#e9 Tom Z wrote: > I would make a broader statement: The application object implementing > PushSupplier (or whatever) should have its disconnect() called any time the > channel and/or admin have chosen to destroy or delete the corresponding > proxy object. Tom, This could be mandated but as Mike correctly pointed out, single threaded clients can not support this functionality (deadlock). We agree that the inability for clients to discover that a third-party destroyed the proxy could be a problem in special situations, but the possible resolutions have too many negative side effects. We could consider a boolean QoS for the notification service, but this is really an event service issue. > I take this to mean a client has only one proxy, and a proxy has only one > client. If so, then yes, I agree, and somebody (Michi? I can look it up) > has stated as such. It might be good to codify this rather than rely on > everyone seeing the same implication. This is why the proxy connect operations may raise the AlreadyConnected exception. > Hmm. This goes beyond the "1-to-1" relationship statement, in my opinion. > What happens w/ federated event channels (the nearest example I can find > is Henning & Vinoski p. 944; I think Doug Schmidt's tutorial shows the > same thing)? When federating, don't we *usually* have a third party per- > forming the connect(), and presumably disconnect(), calls? The great thing about federating channels is that you don't need any intermediators. Federation doesn't introduce any clients that need to get the callback. So we believe this is a notification service implementation detail, unless you can give me an example of a dangling proxy affecting client portability. > After thinking through this, I'm not comfortable with prohibiting 3rd > party objects from calling a proxy's disconnect(). I propose > > 1 A proxy has one client, and a client has one proxy. > 2 When a proxy's disconnect() is called, the proxy shall call the client's > disconnect(). > 3 The proxy's disconnect() shall throw OBJECT_NOT_EXIST if called a 2nd > time. > 4 When a client's disconnect() is called, the client shall call the pro- > xy's disconnect(). > 5 The client shall handle OBJECT_NOT_EXIST exceptions from the proxy's > disconnect(), which is no change from today. > > This way, whenever the proxy or client has their disconnect() called, they > call the other's disconnect(). There are call loops but they are bounded. > Does this cover all the possibilities? I edited your mail and put numbers on those five statements. Point 2 is really the only issue that's up for debate here in our opinion. We disagree with point 4 because it should be an implementation detail of the notification service how and if it detects dangling clients. > Your point about adding invocations is well taken. The only option I can > see to prevent that is to add operations to both the client and proxy (the > names are obviously unsuitable): > proxy::disconnect() [called from channel or admin objects] > proxy::disconnecting() [called from client] > client::disconnect() [called from other application objects] > client::disconnected() [called from proxy] > > The 3rd could be removed and left to the application, if we prohibit the > application from calling the existing client::disconnect(). > > The root of the problem is that for both the client and proxy, disconnect() > can be called from "their side" (channel or admin for the proxy, applica- > tion for the client) or across the application-EventService boundary. We > must either provide a way of distinguishing these or tolerate the extra > calls. We feel that adding these operations bring more confusion to the matter and they are not necessary to devise a solution to this issue. Best regards, Bjarne. Date: Thu, 16 Mar 2000 12:55:25 -0330 From: Brent Eagles To: Bjarne Rasmussen Cc: notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Subject: Re: Issue 3114 Message-ID: <20000316125525.A31283@ooc.com> References: <38CFC1EA.F8FF23BB@us.prismtechnologies.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <38CFC1EA.F8FF23BB@us.prismtechnologies.com> Organization: Object Oriented Concepts, Inc. Content-Type: text/plain; charset=us-ascii X-UIDL: =H`d9kfFe9O8,!!@8S!! Hi, > -- Discussion: > > The above suggestion introduces two problems. The first is that a > client > might not discover if a third-party object disconnects its > proxy. This > is particularly relevant for pull suppliers and push consumers. A > solution could be to always have the proxy do a callback when the > disconnect operation of the proxy is invoked: > > other proxy client > | disconnect | | > |--------------->| disconnect | > | |--------------->| Yes. That is a reasonable scenario. > > The second problem is that proxies might not discover that a client > has > been destroyed. This is particularly relevant for proxy pull > suppliers > and proxy push consumers. However, a difficulty arises when > attempting > to solve this by having the client call the proxy's disconnect > operation > whenever the client's disconnect operation is called: > > other client proxy > | disconnect | | > |--------------->| disconnect | > | |--------------->| > | | disconnect | > | |<---------------| > > As can be seen, the client must have logic to prevent it from > performing > two disconnect calls. We don't think the proxy can detect this > because > it should raise OBJECT_NOT_EXIST if disconnect is called twice. If > the > client detects the disconnect, it will be ok for the client to raise > OBJECT_NOT_EXIST the second time (proxy would ignore this). Note > that > this solution triples the number of calls on channel destruction. What's wrong with the client receiving an OBJECT_NOT_EXIST exception if disconnect is called twice? If the application can make multiple disconnect requests on the same proxy by design, then it should be able to cope with OBJECT_NOT_EXIST exceptions as well. I do not think that this is an unreasonable burden to put on the developer. > > We believe that a requirement for disconnect detection in the client > is > undesirable. Whether or not the notification service can detect > disconnected clients is an implementation issue that could (should?) > be > left out of the specification. An implementation of the notification > service could for instance provide appropriate timeout QoS > properties on > the proxy to support this functionality. There are at least two scenarios where the proxy can determine the the consumer or supplier has 'disappeared' without having been 'told' directly through a disconnect method: 1. it receives an OBJECT_NOT_EXIST exception on a request to the peer object. 2. it receives a CosEventComm_Disconnected exception. As far as I can tell, the spec doesn't say anything about 'detecting' anything. If you call the appropriate disconnect method on the proxy, this is hardly 'detecting'. Its a proactive method of telling the proxy that it should go away. IMO it is wrong for the implementation of 'disconnect*' in a consumer or supplier to call disconnect on its peer proxy. There is nothing in the specification (Event Service or Notification Service) that says a consumer or supplier should attempt to call disconnect on their peer when they go away. It would seem more straightforward for the consumer or supplier to simply disconnect the servant or throw the CosEventComm_Disconnected exception on subsequent requests. > > The first problem does represent an issue, but we feel that there is > an > implied one to one relationship between a client and its proxy. The > client should not expect third-party objects to interact directly > with > their proxy object. If some application decides to disconnect a > third-party proxy, the application should in turn take the > appropriate > actions to also notify the affected client object. But third party objects do interact with the proxy by the very nature of the service. The admin can destroy the proxy if someone destroys the admin. There is no one-to-one relationship between a client and the admin associated with its peer proxy object. Also, this restriction would prohibit the creation of notification service management tools. There is no reason to assume that a consumer or supplier will always be the one to create and destroy its associated proxy. Expecting third party tools to disconnect both the proxy and the client seems awkward. > > To state this a bit more precisely: a client is more often than not > going to disconnect its own proxy. We think this is rarely done by > third-party applications. It seems odd that each call to disconnect > results in a callback to disconnect. Also, while we used to support > exactly this behavior in our product, we changed it because such > callbacks are not supported by certain threading models. I think the presumption that users of the notification service will not want to use separate tools to channel objects unfounded. It seems more unlikely that users will manage proxy/admin/channel lifetimes through the the various consumers and suppliers. Imagine the scenario of 100 consumers. As someone adminstering a running service, would you prefer to call disconnect on 100 consumers, or destroy on one admin or one channel and have the associated proxies take care of the cleanup. The issue of concurrency model is a problem. But this could be dealt with by the implementation of the service by putting a timeout on the request, asynchonously dispatching the disconnect request, etc. > > Best regards, > Bjarne. Best regards, Brent -- Brent Eagles E-Mail: mailto:be@ooc.com Software Developer WWW: http://www.ooc.com/ Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 16 Mar 2000 10:47:25 -0600 From: Bjarne Rasmussen Organization: PrismTech Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Brent Eagles CC: notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Subject: Re: Issue 3114 References: <38CFC1EA.F8FF23BB@us.prismtechnologies.com> <20000316125525.A31283@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =ho!!k\*!!o:0!!O@Nd9 Brent Eagles wrote: > What's wrong with the client receiving an OBJECT_NOT_EXIST exception if > disconnect is called twice? If the application can make multiple disconnect > requests on the same proxy by design, then it should be able to cope with > OBJECT_NOT_EXIST exceptions as well. I do not think that this is an > unreasonable burden to put on the developer. Brent, I certainly didn't mean to imply that this exception is a problem. I think that this exception should be raised on any of the proxy's operations after disconnect has been invoked. > IMO it is wrong for the implementation of 'disconnect*' in a consumer or > supplier to call disconnect on its peer proxy. There is nothing in the > specification (Event Service or Notification Service) that says a consumer > or supplier should attempt to call disconnect on their peer when they > go away. It would seem more straightforward for the consumer or supplier > to simply disconnect the servant or throw the CosEventComm_Disconnected > exception on subsequent requests. Agreed. > But third party objects do interact with the proxy by the very nature > of the service. The admin can destroy the proxy if someone destroys > the admin. There is no one-to-one relationship between a client and > the admin associated with its peer proxy object. And this is why we suggest that the callback happens when the channel (or admin) is destroyed, but not when the proxy is destroyed. Best regards, Bjarne. Date: Thu, 16 Mar 2000 14:03:11 -0330 From: Matthew Newhook To: Bjarne Rasmussen Cc: Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Subject: Re: Issue 3114 Message-ID: <20000316140311.A32163@ooc.com> References: <38CFC1EA.F8FF23BB@us.prismtechnologies.com> <38D01465.E1532050@comm.mot.com> <38D10C48.472C73E1@us.prismtechnologies.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <38D10C48.472C73E1@us.prismtechnologies.com> Content-Type: text/plain; charset=us-ascii X-UIDL: RcB!!ZEBe9IN5!!?Z,e9 Hi, On Thu, Mar 16, 2000 at 10:31:04AM -0600, Bjarne Rasmussen wrote: > Tom Z wrote: > > > I would make a broader statement: The application object > implementing > > PushSupplier (or whatever) should have its disconnect() called any > time the > > channel and/or admin have chosen to destroy or delete the > corresponding > > proxy object. > > Tom, > > This could be mandated but as Mike correctly pointed out, single > threaded > clients can not support this functionality (deadlock). We agree that > the > inability for clients to discover that a third-party destroyed the > proxy could > be a problem in special situations, but the possible resolutions > have too many > negative side effects. We could consider a boolean QoS for the > notification > service, but this is really an event service issue. I totally disagree with that. If the application cannot discover that the proxy has been destroyed via this nice convenient callback then as far as I'm concerned game over. This must be called, IMO. Problems with single threaded ORBs are, again IMO, simply a non-issue. > Best regards, > Bjarne. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 16 Mar 2000 15:03:44 -0330 From: Matthew Newhook To: Bjarne Rasmussen Cc: Brent Eagles , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Subject: Re: Issue 3114 Message-ID: <20000316150344.A32492@ooc.com> References: <38CFC1EA.F8FF23BB@us.prismtechnologies.com> <20000316125525.A31283@ooc.com> <38D1101D.2684A56B@us.prismtechnologies.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <38D1101D.2684A56B@us.prismtechnologies.com> Content-Type: text/plain; charset=us-ascii X-UIDL: \(!!!-!Z!!>;]!!V7He9 Hi, On Thu, Mar 16, 2000 at 10:47:25AM -0600, Bjarne Rasmussen wrote: > > But third party objects do interact with the proxy by the very > nature > > of the service. The admin can destroy the proxy if someone > destroys > > the admin. There is no one-to-one relationship between a client > and > > the admin associated with its peer proxy object. > > And this is why we suggest that the callback happens when the > channel (or admin) > is destroyed, but not when the proxy is destroyed. You are missing the point. Third party objects can destroy the proxy. I don't know why you'd want to make the restriction that you are proposing. It seems to me that a destroy callback (which is what this is) should be called when the proxy is destroyed. Only doing some under some circumstances is: - Inconsistent (callback under some destroy circumstances, but not others) - Suffers from the same problems with single threaded (blocking) ORBs. That is if the client application destroys the channel or the admin you still have a potential deadlock. If I destroy the proxy from within my notification administration GUI I want the consumer or supplier to be notified. If this is not done then the consumer or supplier cannot clean up, and that's unacceptable. > Best regards, > Bjarne. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 16 Mar 2000 16:03:50 -0330 From: Matthew Newhook To: "Michael J. Greenberg" Cc: Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Subject: Re: Issue 3114 Message-ID: <20000316160350.A646@ooc.com> References: <3.0.32.20000316142936.01353460@necsyl01.nectech.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <3.0.32.20000316142936.01353460@necsyl01.nectech.com> Content-Type: text/plain; charset=us-ascii X-UIDL: R&dd9?-Be9e!ed9]CO!! Hi, On Thu, Mar 16, 2000 at 02:29:36PM -0500, Michael J. Greenberg wrote: > With all due respect, but could you explain in technical terms why > you > feel not having the proxy's disconnect operation invoke disconnect > on its > client results in the end of the world as we know it? Our product > currently > works this way and we have many customers who are surviving quite > happily. > Likewise, could you explain why leaving open the possibility of > single-threaded clients should be a non-issue, aside from the fact > that > it's IYO? Read my other mail ;) To summarize: - It's inconsistent. - It doesn't solve the problem -- it avoids it in the case that the client application destroys the proxy, but there is a still a problem if the client application destroys the channel or the admin - It's not a fundamental problem with single threaded ORBs anyway. If the ORB is running a concurrency model that doesn't support callbacks then set whatever QoS property is appropriate on the service so that the method invocation doesn't block forever. - The consumer or supplier will not receive notification that some third party has destroyed the proxy and therefore cannot clean up. > Thanks, > Mike > > -- > Michael J. Greenberg > NEC Systems, Inc. > 305 Foster Street Tel: (978)-742-8127 > Littleton, MA 01460 Fax: (978)-742-8557 > mjg@nectech.com Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 X-Sender: mjg@necsyl01.nectech.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 16 Mar 2000 14:29:36 -0500 To: Matthew Newhook From: "Michael J. Greenberg" Subject: Re: Issue 3114 Cc: Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: *Jd!!epBe9@8Z!!m~&e9 Hi Matthew, >> Tom, >> >> This could be mandated but as Mike correctly pointed out, single >> threaded >> clients can not support this functionality (deadlock). We agree >> that the >> inability for clients to discover that a third-party destroyed the >> proxy could >> be a problem in special situations, but the possible resolutions >> have too many >> negative side effects. We could consider a boolean QoS for the >> notification >> service, but this is really an event service issue. > >I totally disagree with that. If the application cannot discover that >the proxy has been destroyed via this nice convenient callback then >> as >far as I'm concerned game over. This must be called, IMO. Problems >> with >single threaded ORBs are, again IMO, simply a non-issue. With all due respect, but could you explain in technical terms why you feel not having the proxy's disconnect operation invoke disconnect on its client results in the end of the world as we know it? Our product currently works this way and we have many customers who are surviving quite happily. Likewise, could you explain why leaving open the possibility of single-threaded clients should be a non-issue, aside from the fact that it's IYO? Thanks, Mike -- Michael J. Greenberg NEC Systems, Inc. 305 Foster Street Tel: (978)-742-8127 Littleton, MA 01460 Fax: (978)-742-8557 mjg@nectech.com Date: Thu, 16 Mar 2000 20:15:19 -0330 From: Matthew Newhook To: "Michael J. Greenberg" Cc: Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton , bill@nectech.com, be@ooc.com Subject: Re: Issue 3114 Message-ID: <20000316201519.A1902@ooc.com> References: <3.0.32.20000316170745.0138fe6c@necsyl01.nectech.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <3.0.32.20000316170745.0138fe6c@necsyl01.nectech.com> Content-Type: text/plain; charset=us-ascii X-UIDL: HC*!!ki"e9=8^!!di>!! Hi Mike, On Thu, Mar 16, 2000 at 05:07:52PM -0500, Michael J. Greenberg wrote: >[..] > so having the proxy invoke disconnect back on the proxy would be > wasted communication. Even if a third party admin tool invokes > disconnect on the proxy instead of the client, why couldn't this tool > subsequently invoke disconnect on the client? How would the third party tool know the client object? This is not published information -- that is the service itself does not make this known. Without some private communication, or proprietary call, the reference cannot be known. > It's unclear to me why it > is important to couple proxy disconnect with client disconnect in > the > specific manner you propose (because many other legitimate > implementations > are possible). Currently, we (NECSYS) are opposed to making this > change to the specs. If disconnect is not called on the consumers and suppliers of events to/from the service then they cannot know that the proxy has been destroyed in the general case. For push consumers and pull suppliers this is particular problematic since, given that they are proactive, what will actually happen is that they will never receive any further calls (that is events) and it will not be clear why this is the case. The way I see it this as a big problem :( > -Mike > Michael J. Greenberg > NEC Systems, Inc. > 305 Foster Street > Littleton, MA 01460-2004 > VOX: (978)-742-8127 > FAX: (978)-742-8557 > E-mail: mjg@nectech.com Best Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 X-Sender: mjg@necsyl01.nectech.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 16 Mar 2000 22:00:33 -0500 To: Matthew Newhook From: "Michael J. Greenberg" Subject: Re: Issue 3114 Cc: Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton , bill@nectech.com, be@ooc.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: L;!"!6POe9p_L!!)80e9 Hi Matt, Okay, these are valid arguments. I will need to give this some more thought. I do see your points. Still, though, I view this as a very minor problem. As I have stated we have a fairly significant installed base at this point, and no end-user has ever complained about this. -Mike At 08:15 PM 3/16/00 -0330, Matthew Newhook wrote: >Hi Mike, > >On Thu, Mar 16, 2000 at 05:07:52PM -0500, Michael J. Greenberg wrote: >>[..] >> so having the proxy invoke disconnect back on the proxy would be >> wasted communication. Even if a third party admin tool invokes >> disconnect on the proxy instead of the client, why couldn't this tool >> subsequently invoke disconnect on the client? > >How would the third party tool know the client object? This is not >published information -- that is the service itself does not make this >known. Without some private communication, or proprietary call, the >reference cannot be known. > >> It's unclear to me why it >> is important to couple proxy disconnect with client disconnect in the >> specific manner you propose (because many other legitimate implementations >> are possible). Currently, we (NECSYS) are opposed to making this >> change to the specs. > >If disconnect is not called on the consumers and suppliers of events >to/from the service then they cannot know that the proxy has been >destroyed in the general case. > >For push consumers and pull suppliers this is particular problematic >since, given that they are proactive, what will actually happen is that >they will never receive any further calls (that is events) and it will >not be clear why this is the case. > >The way I see it this as a big problem :( > >> -Mike >> Michael J. Greenberg >> NEC Systems, Inc. >> 305 Foster Street >> Littleton, MA 01460-2004 >> VOX: (978)-742-8127 >> FAX: (978)-742-8557 >> E-mail: mjg@nectech.com > >Best Regards, Matthew >-- >Matthew Newhook E-Mail: mailto:matthew@ooc.com >Software Designer WWW: http://www.ooc.com >Object Oriented Concepts, Inc. Phone: (709) 738-3725 > > Michael J. Greenberg NEC Systems, Inc. 305 Foster Street Littleton, MA 01460-2004 VOX: (978)-742-8127 FAX: (978)-742-8557 E-mail: mjg@nectech.com X-Sender: mjg@necsyl01.nectech.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 16 Mar 2000 17:07:52 -0500 To: Matthew Newhook From: "Michael J. Greenberg" Subject: Re: Issue 3114 Cc: Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton , bill@nectech.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: D8[d9oFEe9lR0!!5aF!! Hi Matthew, Thanks for clarifying your arguments in this and your previous message. We are now discussing this issue internally. As I explained previously, our current implementation does not work this way: destruction of channels and admins does cause each client's "disconnect" to be invoked, but proxy disconnection (destruction) does not. This of course was a perfectly legitimate way to implement things in conformance with existing implementations. Now we have a sizeable customer base, not one of which has raised a complaint about this issue. So, while I do see your points, I am not convinced that it is worth incorporating a change to the specs that dictates this specific implementation (that proxy disconnect causes client disconnect to be invoked) at this point. We considered this issue when designing our original implementation. Some rationale for our decision not to have proxy disconnect invoke client disconnect was that it was unclear to us that this was any more legitimate than having client disconnect invoke proxy disconnect. We also envisioned that in the large majority of cases, it would be the client application itself invoking disconnect on the proxy, so having the proxy invoke disconnect back on the proxy would be wasted communication. Even if a third party admin tool invokes disconnect on the proxy instead of the client, why couldn't this tool subsequently invoke disconnect on the client? It's unclear to me why it is important to couple proxy disconnect with client disconnect in the specific manner you propose (because many other legitimate implementations are possible). Currently, we (NECSYS) are opposed to making this change to the specs. -Mike >Read my other mail ;) > >To summarize: > >- It's inconsistent. > >- It doesn't solve the problem -- it avoids it in the case that the client > application destroys the proxy, but there is a still a problem if the > client application destroys the channel or the admin > >- It's not a fundamental problem with single threaded ORBs anyway. > If the ORB is running a concurrency model that doesn't support callbacks > then set whatever QoS property is appropriate on the service so that > the method invocation doesn't block forever. > >- The consumer or supplier will not receive notification that some third > party has destroyed the proxy and therefore cannot clean up. > >> Thanks, >> Mike >> >> -- >> Michael J. Greenberg >> NEC Systems, Inc. >> 305 Foster Street Tel: (978)-742-8127 >> Littleton, MA 01460 Fax: (978)-742-8557 >> mjg@nectech.com > >Regards, Matthew >-- >Matthew Newhook E-Mail: mailto:matthew@ooc.com >Software Designer WWW: http://www.ooc.com >Object Oriented Concepts, Inc. Phone: (709) 738-3725 > > Michael J. Greenberg NEC Systems, Inc. 305 Foster Street Littleton, MA 01460-2004 VOX: (978)-742-8127 FAX: (978)-742-8557 E-mail: mjg@nectech.com Date: Tue, 21 Mar 2000 15:06:00 +1000 (EST) From: Michi Henning To: notif-service-rtf@omg.org Subject: Issue 3114 discussion In-Reply-To: <38CFC1EA.F8FF23BB@us.prismtechnologies.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: nSdd9""#!!Dd_d9]fh!! Hi, I've caught up on the thread for this issue so far and want to put some thoughts down, so here we go... Some observations: 1) The event service uses a fine-grained object model that is built on top of the basic and direct one-to-one consumer-supplier models that are shown on page 4-7 of the spec. 2) The admin and proxy objects serve to separate the concerns of transmission and receipt of events from the concerns of connecting suppliers and consumer into a topology. 3) This object model makes sense only if transmission and receipt of events are seen as orthogonal to topology establishment. Some substantiation (apart form the object model that is in the spec now): 1) Page 4-3 "Objects that use event channels may locate the channels by looking for them in a persistently available server (e.g., by looking for them in a naming service) or they may be given references to these objects as part of a specific-to-task object protocol (e.g., when an "open" operation is invoked on an object, the object may return the reference to an event channel which the caller should use until the object is closed)." This isn't definitive, but offers some evidence as to the intended separation of concerns: "... until the object is closed" at least implicitly permits another party to invoke the "close", that is, disconnect or destroy operation. 2) Page 4-14 "The reason for the two-step registration process is to support composing event channels by an external agent. Such an agent would compose two channels by obtaining a proxy supplier from one and a proxy consumer from the other, and passing each of them a reference to the other as part of their connect operation." This clearly indicates that topology control and event transmission are seen as orthogonal issues. Given that (although the above para only talks about topology establishment), it stands to reason that tearing down a topology should also be seen as an orthogonal concern. 3) The disconnect* operations were added to the spec for a reason: to allow each party to know when the other party is about to go away. Otherwise, there would be no point to having the disconnect* operations at all. Our current problem is that the spec does not answer the following questions: - What should happen if someone calls destroy() on an event channel? - What should happen if someone calls disconnect* on a proxy? The first point appears to be the easier one to address. If an event channel is destroyed, this clearly implies that events must stop flowing. The spec makes this clear in Sectino 4.4. The question is what has to happen in this case. The following points would appear to be non-contentious: 1) Destruction of an event channel implies destruction of all the Consumer and SupplierAdmin objects that were obtained from that channel. 2) Destruction of an event channel implies destruction of all the proxy objects that were created via admin objects for that channel. The contentious point is which disconnect* operation (if any) is invoked when a channel is destroyed, and by whom, and in what order. Some circumstantial evidence for the intent can be found in in the spec. (This is for the ProxyPushConsumer interface; similar words are used for the other models.) A nil object reference may be passed to the connect_push_supplier operation; if so a channel cannot invoke the disconnect_push_supplier operation on the supplier; the supplier may be disconnected from the channel without being informed. This says that if the callback reference is nil, the supplier cannot expect to be informed of disconnection. The problem is that the spec only says something about what happens when a nil reference is passed, but doesn't say anything about what happens when a non-nil reference is passed. It is illegal in formal logic to drive implication in the reverse direction; however, I believe that what is meant here was equivalence, not implication. In other words, the intent was that the supplier can expect to be informed of disconnection if it passed a non-nil callback reference; otherwise, there would be no point in having a disconnect* operation in the first place. Proposal: For channel destruction, the behavior should be as follows: 1) The channel enters a state in which it delivers no more events to push consumers via push() calls and in which it ceases to call pull() on its pull suppliers. Simultaneously, the channel blocks all push suppliers in their push() operations and blocks all pull consumers in their pull() operations. 2) The channel discards all buffered events. 3) The channel invokes the disconnect operation on all proxies that have registered non-nil callbacks: - For each proxy on which the disconnect operation has completed successfully: - if a consumer is blocked in a pull() operation, that consumer's pull() operation terminates with OBJECT_NOT_EXIST - if a supplier is blocked in a push() oepration, that that supplier's push() operation terminates with OBJECT_NOT_EXIST 4) The channel raises OBJECT_NOT_EXIST for all proxies for which no callback was registered. Rationale: The above suggested sequence prevents a number of object leak scenarios and permits either party to learn about the fact that the other party is about to go away. This is particularly important for the server side of a connection because, without a disconnect callback, the server side of a connection doesn't know at all that a channel has been destroyed (because the server cannot tell permanent destruction from a long silence). The other issue relates to what should happen when some party invokes the disconnect operation on a proxy. I see no basic difference in the fundamental scenario, that is, as a consumer or supplier of a channel, I expect to be informed if I have registered a callback with the channel. Whether I call the disconnect or destroy operation myself or whether that is done by a third party is irrelevant. So, the implementation of disconnect* in the proxy should be to invoke the callback operation (if one was registered). Some objections were raised with respect to this: - There is potential danger of infinite recursive nested callbacks. I don't see this as a problem. By doing things in the correct order, this can easily be prevented. For example: class PushConsumer_impl : public virtual POA_CosEventChannelAdmin::ProxyPushConsumer { public: PushConsumer_impl() : disconnected(false) {} void push(const CORBA::Any & data) throw( CORBA::SystemException, CosEventComm::Disconnected ); // ... private: bool disconnected = false; CosEventComm::PushSupplier_var callback; }; void MyPushConsumer_impl:: push(const CORBA::Any & data) throw(CORBA::SystemException, CosEventComm::Disconnected) { if (disconnected) throw CORBA::OBJECT_NOT_EXIST; // Process event data... } void MyPushConsumer_impl:: disconnect_push_consumer() { if (!disconnected) { // If we are called for the first time, set // disconnected to true. disconnected = TRUE; // Now we accept no more push() operations. // Inform the supplier callback that we are // about to go away. if (!CORBA::is_nil(callback)) { try { callback->disconnect_push_supplier(); } catch (const CORBA::OBJECT_NOT_EXIST &) { // Ignore -- the supplier already // knows this. } callback = CosEventComm::PushSupplier::_nil(); } } else { // We are disconnected already, let the caller know. throw CORBA::OBJECT_NOT_EXIST; } } There are other ways of dealing with this scenario, depending on the POA policies for the proxies. The point is that infinite recursion is trivial to prevent. - Nested callbacks lead to deadlock for some (non)threading models. I also do not see this as a problem: - The event service designers presumably were aware of this issue but did not change the design because of it. - Quite a few ORBs implement reactive call dispatch, which allows even single-threaded clients to accept an incoming call while an outgoing call is outstanding. - There are other services that rely on the callback pattern and they also tacitly assume that nested callbacks are not a problem. One such example is the trader service, which uses callbacks for dynamic property evaluation. - The number of calls on channel destruction would triple. I don't think it would triple. Instead, there would be two remote calls instead of one. Given that channel destruction is rare, and that we have no problem requiring several calls for connection establishment, I don't see this as having any effect whatsoever. If the channel during its lifetime transmits more than twenty events, the incremental cost of the extra call is already unnoticably small. - The client should not expect third-party objects to interact directly with their proxy object. [...] A client is more often than not going to disconnect its own proxy. Given the words in the spec, the object model, and a number of current applications I am aware of, that assumption is not warranted, IMO. The object model (deliberately, I believe) permits a third party to initiate disconnect, and there are a number of applications that use precisely that feature. Further, prohibiting a third party to disconnect would prevent administration tools from doing this too, which wouldn't be practical, IMO. I believe that our job is to make disconnection work, not to forbid it for third parties (which, at any rate, is something we cannot enforce). The alternatives, namely, to not invoke the disconnect operation on the other party in response to a disconnect call, is much more unpleasant: the server side of a connection would have no idea that disconnection has taken place, resulting in a object leak. The only defense against this sort of thing is heuristic garbage collection (which is quite complex to implement and, at any rate, not 100% reliable). Fundamentally, I believe that, if I have an event service that works and that I have connectivity to, I should be entitled to have that service let me know when it is time for me to reap my server object. Otherwise, we have a fundamentally broken design that forces applications into garbage collection. When you think about it, the disconnect operations are really misnamed anyway -- a more appropriate name would have been destroy() because that is precisely what the disconnect operations are -- they end the life time of a proxy. (The reason that they are not called destroy or LifeCycleObject::remove is that the life cycle service was developed concurrently with the event service and that the convention of using destroy() as the destructor name wasn't firmly established at that time.) As far as backward compatibility is concerned, I don't think requiring the callback to be issued by the channel on proxy destruction would cause problems. Consider: - The application, if it has supplied a non-nil callback reference, *expects* to be called back. So, the callback itself can't cause a problem to the application. - The event service proxy will *expect* that, by the time it calls a disconnect operation on an application object, it may get an OBJECT_NOT_EXIST exception, so this can't cause surprises. - The event service proxy will reply to a recursive disconnect call from an application with OBJECT_NOT_EXIST; because that exception can be raised at any time without warning anyway, the application must already be prepared to get it. To me, it looks like correct implementation of the proxy is sufficient to prevent those scenarios that could break existing compliant code, and it is sufficient to prevent infinite recursion. So, overall, I believe we should mandate proxy behavior along the lines I have outlined. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: dyc@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Michael J. Greenberg" cc: Matthew Newhook , Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton , bill@nectech.com, be@ooc.com Message-ID: <852568B2.0059E9F3.00@d54mta08.raleigh.ibm.com> Date: Thu, 30 Mar 2000 10:13:35 -0600 Subject: Re: Issue 3114 Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: D"De97VK!!G`0e9gBid9 Mike, I am late to join this discussion but I have followed your discussion. 1)First of all, we have to limit the function of the "disconnect_xxxx_xxxxx()" method on both the push/pull consumer/supplier client object and the proxy objects to avoid unnecessary complexity of the Event Service. - Even it is not clearly defined in the Event Service spec, the "disconnect_xxxx_xxxxxx()" method of the client object should only invoked by its corresponding proxy objects during the destruction of its proxy object if the client is registered with its object reference with the Event Channel in the "connect_xxxx_xxxxxx()" method. Note that it is not necessary for the client object to register with the Event Channel if a null object is passed to the Event Channel in the "connect_xxxx_xxxxx()" method. - In the CORBA architecture, if a client is expected to provide the "disconnect_xxxx_xxxxx()" method for its proxy object to call-back, it should be implemented as a CORBA server even some vendor provide a proprietary solution for the client to provide a call-back feature in the CORBA client. - The Event Channel or the Admin object should not call the "disconnect_xxxx_xxxxx()" method of the proxy object to destroy the proxy object instead it should invoke the destructor of the proxy object. - The "disconnect_xxxx_xxxxx()" method of the proxy object should only be called by the client object to inform the disconnection of communication between the client object and the proxy object. The implementation of the "disconnect_xxxx_xxxxx()" method of the proxy object can set a "termination flag" in the proxy object to indicate the termination of the communication between the proxy object and the client object and stop to receive any events in the queue. This is a implementation details. The "disconnect_xxxx_xxxxx()" method of the proxy object should not invoke the "disconnect_xxxx_xxxxx()" method of the client object to avoid a recursive scenario. - The destructor o the proxy object will invoke the "disconnect_xxxx_xxxxx()" method which will invoke the "disconnect_ xxxx_xxxxxx()" method of the client object if the client object is registered with the Event Channel at the "connect_xxxx_xxxxxx()" method invocation and the "termination flag" is not set. 2)Since the implementation details of above description should not impact the interoperability of the Event Channel implementation between vendors, it is not necessary to change the Event Service spec for this reason. However, it is a good idea to clearly define the purpose of the "disconnect_xxxx_xxxxx()" of the client and the proxy object to avoid any further confusion. I agree with Mike the call-back "disconnect_xxxx_xxxxx()" feature at the client is a big performance hit for the destructon of the Event Channel. In our implementation, we advise our customers to deploy this feature cautiously. Best Regards, David Chang WebSphere, Security Service Development IBM SWS Division, Internal Mail Stop 9640 Austin, Tx 78758 E-Mail:dyc@us.ibm.com Phone:(512)838-0559, T/L 678-0559 Fax: (512)838-1032 "Michael J. Greenberg" on 03/16/2000 09:00:33 PM To: Matthew Newhook cc: Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton , bill@nectech.com, be@ooc.com Subject: Re: Issue 3114 Hi Matt, Okay, these are valid arguments. I will need to give this some more thought. I do see your points. Still, though, I view this as a very minor problem. As I have stated we have a fairly significant installed base at this point, and no end-user has ever complained about this. -Mike At 08:15 PM 3/16/00 -0330, Matthew Newhook wrote: >Hi Mike, > >On Thu, Mar 16, 2000 at 05:07:52PM -0500, Michael J. Greenberg wrote: >>[..] >> so having the proxy invoke disconnect back on the proxy would be >> wasted communication. Even if a third party admin tool invokes >> disconnect on the proxy instead of the client, why couldn't this tool >> subsequently invoke disconnect on the client? > >How would the third party tool know the client object? This is not >published information -- that is the service itself does not make this >known. Without some private communication, or proprietary call, the >reference cannot be known. > >> It's unclear to me why it >> is important to couple proxy disconnect with client disconnect in the >> specific manner you propose (because many other legitimate implementations >> are possible). Currently, we (NECSYS) are opposed to making this >> change to the specs. > >If disconnect is not called on the consumers and suppliers of events >to/from the service then they cannot know that the proxy has been >destroyed in the general case. > >For push consumers and pull suppliers this is particular problematic >since, given that they are proactive, what will actually happen is that >they will never receive any further calls (that is events) and it will >not be clear why this is the case. > >The way I see it this as a big problem :( > >> -Mike >> Michael J. Greenberg >> NEC Systems, Inc. >> 305 Foster Street >> Littleton, MA 01460-2004 >> VOX: (978)-742-8127 >> FAX: (978)-742-8557 >> E-mail: mjg@nectech.com > >Best Regards, Matthew >-- >Matthew Newhook E-Mail: mailto:matthew@ooc.com >Software Designer WWW: http://www.ooc.com >Object Oriented Concepts, Inc. Phone: (709) 738-3725 > > Michael J. Greenberg NEC Systems, Inc. 305 Foster Street Littleton, MA 01460-2004 VOX: (978)-742-8127 FAX: (978)-742-8557 E-mail: mjg@nectech.com Date: Thu, 30 Mar 2000 13:00:21 -0330 From: Matthew Newhook To: dyc@us.ibm.com Cc: "Michael J. Greenberg" , Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton , bill@nectech.com, be@ooc.com Subject: Re: Issue 3114 Message-ID: <20000330130020.A3207@ooc.com> References: <852568B2.0059E9F3.00@d54mta08.raleigh.ibm.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <852568B2.0059E9F3.00@d54mta08.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii X-UIDL: lC2!!Q8$"!oTN!!Rp\d9 Hi, On Thu, Mar 30, 2000 at 10:13:35AM -0600, dyc@us.ibm.com wrote: > > > Mike, > > I am late to join this discussion but I have followed your > discussion. > > 1)First of all, we have to limit the function of the > "disconnect_xxxx_xxxxx()" method on both > the push/pull consumer/supplier client object and the proxy > objects to > avoid unnecessary > complexity of the Event Service. > > - Even it is not clearly defined in the Event Service spec, the > "disconnect_xxxx_xxxxxx()" method > of the client object should only invoked by its corresponding > proxy > objects during the destruction > of its proxy object if the client is registered with its object > reference with the Event Channel in the > "connect_xxxx_xxxxxx()" method. Note that it is not necessary > for the > client object to register with the > Event Channel if a null object is passed to the Event Channel > in the > "connect_xxxx_xxxxx()" method. >[...] Sorry, I don't agree with any of this mail. You have a particular view of how the service is used which is contrary to my view (and of more interest to us -- how our paying customers use the service). See Michi's mail on this topic for a clear and full explanation why and how the service should work. > Best Regards, > > > > David Chang > > WebSphere, Security Service Development > IBM SWS Division, Internal Mail Stop 9640 > Austin, Tx 78758 > E-Mail:dyc@us.ibm.com > Phone:(512)838-0559, T/L 678-0559 > Fax: (512)838-1032 Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Reply-To: From: "Bill Kanawyer" To: "Matthew Newhook" , Cc: "Michael J. Greenberg" , "Bjarne Rasmussen" , "Tom Z" , , "Paul Moxon" , "Steve Osselton" , Subject: RE: Issue 3114 Date: Thu, 30 Mar 2000 11:57:00 -0500 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20000330130020.A3207@ooc.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: =Ko!!"G)e9Ndod9hofd9 All, I've been monitoring this discussion, but haven't had any new technical insights to add to date. However Mr. Chang's message does underscore that there are differing opinions on how the service should be implemented. Because of this, I am in favor of making the disconnect callback requirement configurable rather then mandatory. I think the arguments in favor of mandating the behavior are very solid technically, but not fully compelling. Also our customer base (OrbixNotification and NEC internal) have made no great demands for this capability. Mike Greenberg is the official NEC representative and will be voting as he thinks best. In his place however I would vote "no" on this RFC if it mandates the proposed disconnect behavior. I would vote "yes" if the behavior was configurable in some manner (e.g. a new proxy QoS), but I understand that may be beyond the scope of an RFC. Bill Kanawyer Principal Software Engineer NEC Systems, Inc. 305 Foster St. Littleton, MA 01460-2004 (609) 395-1108 bill@nectech.com -----Original Message----- From: Matthew Newhook [mailto:matthew@ooc.com] Sent: Thursday, March 30, 2000 11:30 AM To: dyc@us.ibm.com Cc: Michael J. Greenberg; Bjarne Rasmussen; Tom Z; notif-service-rtf@omg.org; Paul Moxon; Steve Osselton; bill@nectech.com; be@ooc.com Subject: Re: Issue 3114 Hi, On Thu, Mar 30, 2000 at 10:13:35AM -0600, dyc@us.ibm.com wrote: > > > Mike, > > I am late to join this discussion but I have followed your > discussion. > > 1)First of all, we have to limit the function of the > "disconnect_xxxx_xxxxx()" method on both > the push/pull consumer/supplier client object and the proxy > objects to > avoid unnecessary > complexity of the Event Service. > > - Even it is not clearly defined in the Event Service spec, the > "disconnect_xxxx_xxxxxx()" method > of the client object should only invoked by its corresponding > proxy > objects during the destruction > of its proxy object if the client is registered with its object > reference with the Event Channel in the > "connect_xxxx_xxxxxx()" method. Note that it is not necessary > for the > client object to register with the > Event Channel if a null object is passed to the Event Channel > in the > "connect_xxxx_xxxxx()" method. >[...] Sorry, I don't agree with any of this mail. You have a particular view of how the service is used which is contrary to my view (and of more interest to us -- how our paying customers use the service). See Michi's mail on this topic for a clear and full explanation why and how the service should work. > Best Regards, > > > > David Chang > > WebSphere, Security Service Development > IBM SWS Division, Internal Mail Stop 9640 > Austin, Tx 78758 > E-Mail:dyc@us.ibm.com > Phone:(512)838-0559, T/L 678-0559 > Fax: (512)838-1032 Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 30 Mar 2000 13:35:20 -0330 From: Matthew Newhook To: Bill Kanawyer Cc: dyc@us.ibm.com, "Michael J. Greenberg" , Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton , be@ooc.com Subject: Re: Issue 3114 Message-ID: <20000330133519.A3590@ooc.com> References: <20000330130020.A3207@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: \X-!!_D8e9O82!!]!>e9 Hi Bill, On Thu, Mar 30, 2000 at 11:57:00AM -0500, Bill Kanawyer wrote: > I would vote "yes" if the behavior was configurable > in some manner (e.g. a new proxy QoS), but I understand that may be > beyond > the scope of an RFC. How does this work with the event service since the event service has no QoS framework? I think that we should come up with clear, consise and consistent semantics for the proxy disconnection. Both from the point of view of the channel and from the point of view of the proxy. Personally, I think that Michi's mail was clear and consise and I have neither heard nor seen any rebuttle to the technical points in his mail. That being said I realize that there are, as always, political reasons why the technically correct solution may not be accepted. > Bill Kanawyer > Principal Software Engineer > NEC Systems, Inc. > 305 Foster St. > Littleton, MA 01460-2004 > (609) 395-1108 > bill@nectech.com Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Reply-To: From: "Bill Kanawyer" To: "Matthew Newhook" Cc: , "Michael J. Greenberg" , "Bjarne Rasmussen" , "Tom Z" , , "Paul Moxon" , "Steve Osselton" , Subject: RE: Issue 3114 Date: Thu, 30 Mar 2000 13:50:05 -0500 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20000330133519.A3590@ooc.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: j:Xd9YQBe9RfJe97`Qd9 Matthew, As I said, the technical recommendations for modification this are clear and sound. However there is now a history of implementations, including Event servers, that may or may not support this behavior. Support for applications built to these older releases is part of the reason you should think carefully about mandating the proposed behavior. I understand it's not possible to use QoS on pure Event style proxies. (That's why "e.g." rather then "i.e." in my original posting.) I'm happy to listen to alternatives to QoS to make this configurable. If this change is being driven by the holy grail of orb interoperability then I think we have other, more serious, impediments in the way. If this change is being driven to "bless" someone's particular implementation, then I think it's just plain wrong-headed to start with. However if this request is intended to permit more uniform behavior in cases where an administration management tool is used, then I feel that making it configurable is the best option at this point in time. We, of course, remain ready to implement the changes if the consensus is to accept the proposal. Cheers! Bill Kanawyer Principal Software Engineer NEC Systems, Inc. 305 Foster St. Littleton, MA 01460-2004 (609) 395-1108 bill@nectech.com -----Original Message----- From: Matthew Newhook [mailto:matthew@ooc.com] Sent: Thursday, March 30, 2000 12:05 PM To: Bill Kanawyer Cc: dyc@us.ibm.com; Michael J. Greenberg; Bjarne Rasmussen; Tom Z; notif-service-rtf@omg.org; Paul Moxon; Steve Osselton; be@ooc.com Subject: Re: Issue 3114 Hi Bill, On Thu, Mar 30, 2000 at 11:57:00AM -0500, Bill Kanawyer wrote: > I would vote "yes" if the behavior was configurable > in some manner (e.g. a new proxy QoS), but I understand that may be > beyond > the scope of an RFC. How does this work with the event service since the event service has no QoS framework? I think that we should come up with clear, consise and consistent semantics for the proxy disconnection. Both from the point of view of the channel and from the point of view of the proxy. Personally, I think that Michi's mail was clear and consise and I have neither heard nor seen any rebuttle to the technical points in his mail. That being said I realize that there are, as always, political reasons why the technically correct solution may not be accepted. > Bill Kanawyer > Principal Software Engineer > NEC Systems, Inc. > 305 Foster St. > Littleton, MA 01460-2004 > (609) 395-1108 > bill@nectech.com Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 30 Mar 2000 15:28:02 -0330 From: Matthew Newhook To: Bill Kanawyer Cc: dyc@us.ibm.com, "Michael J. Greenberg" , Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton , be@ooc.com Subject: Re: Issue 3114 Message-ID: <20000330152802.A4275@ooc.com> References: <20000330133519.A3590@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: G>\!! Matthew, > > As I said, the technical recommendations for modification this > are clear and sound. However there is now a history of > implementations, > including Event servers, that may or may not support this behavior. > Support for applications built to these older releases is > part of the reason you should think carefully about mandating > the proposed behavior. > > I understand it's not possible to use QoS on pure Event style > proxies. (That's why "e.g." rather then "i.e." in my original > posting.) I'm happy to listen to alternatives to QoS to make > this configurable. > > If this change is being driven by the holy grail of orb > interoperability then I think we have other, more serious, > impediments in the way. It's nothing to do with ORB interoperatibility -- it's how to write portable event & notification service applications. Anyway, for that matter what's the problem with ORB interop? > If this change is being driven to "bless" someone's particular > implementation, then I think it's just plain wrong-headed to start > with. Why do you think this? > However if this request is intended to permit more uniform behavior > in cases where an administration management tool is used, then I > feel > that making it configurable is the best option at this point in > time. Admin management tools are not the heart of the matter. The question is what happens on disconnection from the service? How can applications disconnect, etc. Admin tools happen to be one way to cause this to occur. > We, of course, remain ready to implement the changes if the consensus > is to accept the proposal. We need to clarify the disconnection semantics since the spec isn't clear. Currently it's not possible to write portable applications since developers cannot rely on any sort of reasonable disconnection semantics from the service. > Cheers! > > Bill Kanawyer > Principal Software Engineer > NEC Systems, Inc. > 305 Foster St. > Littleton, MA 01460-2004 > (609) 395-1108 > bill@nectech.com Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Fri, 31 Mar 2000 10:28:56 +1000 (EST) From: Michi Henning To: Bill Kanawyer cc: Matthew Newhook , dyc@us.ibm.com, "Michael J. Greenberg" , Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton , be@ooc.com Subject: RE: Issue 3114 In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2oXd93L8!!Hj3e9I$0!! On Thu, 30 Mar 2000, Bill Kanawyer wrote: > However Mr. Chang's message does underscore that there > are differing opinions on how the service should be > implemented. Because of this, I am in favor of making > the disconnect callback requirement configurable rather > then mandatory. I'm generally against using optional or configurable features. That's simply because it still doesn't allow me to write portable code. If the wrong config options are set (or an option isn't supported), I end up with non-portable code that does the wrong thing. > I think the arguments in favor of mandating the behavior > are very solid technically, but not fully compelling. Also > our customer base (OrbixNotification and NEC internal) > have made no great demands for this capability. I previously pointed out that not calling the disconnect* operations results in object leaks. I don't understand how this, even theoretically, could be considered acceptable. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 31 Mar 2000 10:58:35 +1000 (EST) From: Michi Henning Reply-To: notif-service-rtf@omg.org To: dyc@us.ibm.com cc: "Michael J. Greenberg" , Matthew Newhook , Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton , bill@nectech.com, be@ooc.com Subject: Re: Issue 3114 In-Reply-To: <852568B2.0059E9F3.00@d54mta08.raleigh.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: iBMe9ZXpd9OIQd9a1~e9 On Thu, 30 Mar 2000 dyc@us.ibm.com wrote: Some comments: > - Even it is not clearly defined in the Event Service spec, the > "disconnect_xxxx_xxxxxx()" method > of the client object should only invoked by its corresponding > proxy > objects during the destruction > of its proxy object if the client is registered with its object > reference with the Event Channel in the > "connect_xxxx_xxxxxx()" method. There is no way to enforce this restriction. As I explained in my previous e-mail, I am aware of currently deployed systems which rely on a third party to be able to disconnect. (And no, these are not ORBacus deployed applications -- the ones I'm talking about go back several years and use a different product.) > - In the CORBA architecture, if a client is expected to provide the > "disconnect_xxxx_xxxxx()" method > for its proxy object to call-back, it should be implemented as a CORBA > server even some vendor > provide a proprietary solution for the client to provide a call-back > feature in the CORBA client. I'm not sure I understand. Basically, the whole object model for the event service is designed using the callback pattern. In effect, there is fundamental assumption built into the service object model that clients are able to respond to callbacks (at least if they pass a non-nil callback reference). The service simply requires this, and I see no way around that. In addition, all modern ORBs can handle nested callbacks back to clients, so I don't see that as a problem. > - The Event Channel or the Admin object should not call the > "disconnect_xxxx_xxxxx()" method of the proxy > object to destroy the proxy object instead it should invoke the > destructor of the proxy object. I don't understand this argument. A proxy doesn't have a separate destructor. The disconnect operation *is* the destructor. > - The "disconnect_xxxx_xxxxx()" method of the proxy object should only be > called by the client object > to inform the disconnection of communication between the client object > and the proxy object. The > implementation of the "disconnect_xxxx_xxxxx()" method of the proxy > object can set a "termination flag" in the > proxy object to indicate the termination of the communication between > the proxy object and the > client object and stop to receive any events in the queue. This is a > implementation details. > The "disconnect_xxxx_xxxxx()" method of the proxy object should not > invoke the "disconnect_xxxx_xxxxx()" > method of the client object to avoid a recursive scenario. I don't believe that this is a technically defensible argument. Consider the following situation: push pull Channel A <-------- Channel B --------> Channel C ^ | | ^ pull | | | | push Consumer 1 ---------+ | | +--------- Supplier 1 | | push | | pull Consumer 2 <----------+ +----------> Supplier 2 Here, we have connected three channels into a federation, with B pushing into A cand pulling from C. In addition, B has both pull and push suppliers and consumers (and, in addition A and C might have their own set of supplies and consumers). Now, I may want to remove the connection between A and B to stop events flowing between A and B, or I may want to remove the connection between B and C, for the same reason. However, because both A and C may have their own set of consumers, I can't call destroy on the channel. So, the *only* way to manipulate the federation is to have a third party make the disconnect call. If the disconnect callbacks are not called, those channels that are in the server role have no idea that their supplier or consumer has gone away and we create an object leak. > - The destructor o the proxy object will invoke the > "disconnect_xxxx_xxxxx()" method which > will invoke the "disconnect_ xxxx_xxxxxx()" method of the client > object > if the client object is registered with the Event Channel at the > "connect_xxxx_xxxxxx()" method invocation and the "termination flag" > is not > set. As I said, there *is* no destructor. The disconnect operation *is* the destructor. > 2)Since the implementation details of above description should not impact > the interoperability of the Event > Channel implementation between vendors, it is not necessary to change > the Event Service spec for this reason. > However, it is a good idea to clearly define the purpose of the > "disconnect_xxxx_xxxxx()" of the client and > the proxy object to avoid any further confusion. I agree with Mike the > call-back "disconnect_xxxx_xxxxx()" > feature at the client is a big performance hit for the destructon of > the Event Channel. In our implementation, > we advise our customers to deploy this feature cautiously. Again, I can't see this as a technically defensible argument. An event channel presumably delivers hundreds or thousands of events during its life time and, presumably, hundreds or thousands of events during the life time of a particular proxy. The overhead of the extra callback in this case is completely unnoticable. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 31 Mar 2000 11:04:49 +1000 (EST) From: Michi Henning Reply-To: notif-service-rtf@omg.org To: Bill Kanawyer cc: Matthew Newhook , dyc@us.ibm.com, "Michael J. Greenberg" , Bjarne Rasmussen , Tom Z , notif-service-rtf@omg.org, Paul Moxon , Steve Osselton , be@ooc.com Subject: RE: Issue 3114 In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: %pXd9&%fd9Kgid9B&=e9 On Thu, 30 Mar 2000, Bill Kanawyer wrote: > Matthew, > > As I said, the technical recommendations for modification this > are clear and sound. However there is now a history of > implementations, > including Event servers, that may or may not support this behavior. > Support for applications built to these older releases is > part of the reason you should think carefully about mandating > the proposed behavior. Bill, what I don't understand is how an implementation that leaves an object leak behind could ever be considered acceptable in the first place. As far as I can see, leaving proxies that are in the server role hanging doesn't do anyone any favors. > I understand it's not possible to use QoS on pure Event style > proxies. (That's why "e.g." rather then "i.e." in my original > posting.) I'm happy to listen to alternatives to QoS to make > this configurable. > > If this change is being driven by the holy grail of orb > interoperability then I think we have other, more serious, > impediments in the way. No, there is no holy grail there. The issue is simply about portability. I can't write portable code unless I have defined semantics. Interoperability comes into this too though, namely, when event channels are federated across different implementations. They have to agree on the behavior, otherwise federation is not possible. > If this change is being driven to "bless" someone's particular > implementation, then I think it's just plain wrong-headed to start > with. As far as I know, we have a wide variety of different implementations out there at the moment. I have seen all three behaviors from different implementations: no callback at all, callback only on destruction of the channel, callback in only one direction when the proxy is destroyed, and callback in both directions when the proxy is destroyed. This is not acceptable because neither portability nor interoperability are provided that way. > However if this request is intended to permit more uniform behavior > in cases where an administration management tool is used, then I > feel > that making it configurable is the best option at this point in > time. > > We, of course, remain ready to implement the changes if the > consensus > is to accept the proposal. As I indicated in my other mail, the problems with configuration are: - not standardized - no IDL to enquire about the configuration - channel disconnection is safe only if I tacitly assume that the configuration is known and fixed - portable code can't be written - federation across different vendors and configurations won't work So, basically, I'd like to avoid the configuration path, simply because I don't see it as adding any real value. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 13 Apr 2000 10:16:53 -0500 From: Bjarne Rasmussen Organization: PrismTech Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: notif-service-rtf@omg.org Subject: Re: Proposals? References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [_6!!KD@e9?RGe93M"!! Michi Henning wrote: > Also, on 3114, I have not heard anything from anyone about the issues I > raised regarding disconnect behavior. I'm not comfortable about putting > a proposal for this issue to vote unless we've had some discussion of > these technical issues. I believe we posted a concrete proposal on issue 3114: 1. The client's disconnect operation is only called when the channel (or admin) object is destroyed. I accept that clients may not be informed about proxy destruction is all cases, but prefer this simplicity over complicated callback sequences. Clients must always be able to handle a OBJECT_NOT_EXIST system exception. 2. The ability for a proxy to discover that a client is destroyed is an implementation issue. A (poor) implementation may leak objects as you stated. A better implementation may use timeouts (push supplier and pull consumer) or maximum reconnect attempts (pull supplier and push consumer) to handle this. If a persistent push consumer object is passivated while a third-party disconnects its proxy, that consumer will not be informed about proxy destruction either. I believe it's difficult to cover all situations, in which case I prefer a simple solution. I guess some of the controversy arrises if you can't accept the second item above. Finally, I think it's dangerous to assume that clients always invoke the proxy's disconnect operation in their own disconnect operation (some application developers will forget to do this). With the above suggestion, clients may or may not do this - but they should always be prepared to handle an OBJECT_NOT_EXIST exception. I would support a QoS for the notification service to enable or disable the callbacks. Best regards, Bjarne. Date: Tue, 7 Nov 2000 15:27:25 +1000 (EST) From: Michi Henning To: notif-service-rtf@omg.org, event-rtf@omg.org Subject: Issue 3114 proposal Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2005018665-992951867-973574845=:2361" X-UIDL: ^fkd9<8Ae98o`!!"oEe9 [ Juergen, can you please put a copy of this e-mail on the server as vote 1 for both event and notification RTFs (including the attached PDF) and let us know what the URL is? ] Hi, attached is the vote for issue 3114. This issue affects both the event service and (by inheritance) the notification service. However, no text changes are required for the notification service document -- the notification service spec gets fixed by the fact that it inherits from the event service and therefore must honor the behavior of the base interfaces. 3114 is unusual in that it affects both services, so we will have to vote twice, once on the event-rtf and once on notif-service-rtf. Seeing that both RTFs have actually the same voting members, I would not expect that to be any great problem :-) Attached is the proposal for 3114 as a PDF file. I've used change bars to indicate where the document was edited. [ Sorry, I tried to use the Frame diff tool, but it doesn't work because someone has messed with the flows in the original Frame source, which breaks the diff utility :-( ] The changes are all additions, with two exceptions: on pages 2-11 and 2-12, I changed an occurrence of "should" to "shall" because the text was otherwise not normative: Implementations *shall* raise the CORBA standard BAD_PARAM exception if a nil reference is passed... I think we can deal with this as an editorial change. Speak up if you disagree. Please cast your votes by Monday, 13 October. If you intend to vote differently in the event RTF and the notification RTF for some reason, please indicate so clearly; otherwise, I will assume that you are casting the same vote for both RTFs. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html [] 2_modules_draft1.pdf Reply-To: From: "Andy Till" To: "'Michi Henning'" Cc: , Subject: RE: Issue 3114 proposal Date: Wed, 8 Nov 2000 02:06:46 +0800 Message-ID: <002a01c048e5$7f041ae0$6d85413f@iona.com.au> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: c:3e9W]i!!BB~e90Q1!! Michi, I vote yes for both events and notification. Andy > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: 07 November 2000 13:27 > To: notif-service-rtf@omg.org; event-rtf@omg.org > Subject: Issue 3114 proposal > > > [ Juergen, can you please put a copy of this e-mail on the > server as vote 1 > for both event and notification RTFs (including the > attached PDF) and > let us know what the URL is? ] > > Hi, > > attached is the vote for issue 3114. This issue affects both the event > service and (by inheritance) the notification service. > However, no text > changes are required for the notification service document -- > the notification > service spec gets fixed by the fact that it inherits from the > event service > and therefore must honor the behavior of the base interfaces. > > 3114 is unusual in that it affects both services, so we will > have to vote > twice, once on the event-rtf and once on notif-service-rtf. > Seeing that > both RTFs have actually the same voting members, I would not > expect that > to be any great problem :-) > > Attached is the proposal for 3114 as a PDF file. I've used change bars > to indicate where the document was edited. [ Sorry, I tried > to use the Frame > diff tool, but it doesn't work because someone has messed > with the flows > in the original Frame source, which breaks the diff utility :-( ] > > The changes are all additions, with two exceptions: on pages > 2-11 and 2-12, > I changed an occurrence of "should" to "shall" because the > text was otherwise > not normative: > > Implementations *shall* raise the CORBA standard > BAD_PARAM exception > if a nil reference is passed... > > I think we can deal with this as an editorial change. Speak > up if you disagree. > > Please cast your votes by Monday, 13 October. If you intend > to vote differently > in the event RTF and the notification RTF for some reason, > please indicate > so clearly; otherwise, I will assume that you are casting the > same vote > for both RTFs. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > > Sender: tomz@cc701.comm.mot.com Message-ID: <3A086C84.42119C3F@comm.mot.com> Date: Tue, 07 Nov 2000 14:56:36 -0600 From: Tom Z X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: notif-service-rtf@omg.org, event-rtf@omg.org Subject: Re: Issue 3114 proposal References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %l)!!2jO!!=S7!!@2c!! Well I don't get to vote but this mod appears to satisfactorily address the issue I raised. Only comment I have is in section 2.1.3, "cause" should be "causes". Tom Z, Motorola Date: Wed, 8 Nov 2000 06:59:08 +1000 (EST) From: Michi Henning To: Tom Z cc: notif-service-rtf@omg.org, event-rtf@omg.org Subject: Re: Issue 3114 proposal In-Reply-To: <3A086C84.42119C3F@comm.mot.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: >:'e9XHl!!7Im!!?48!! On Tue, 7 Nov 2000, Tom Z wrote: > Well I don't get to vote but this mod appears to satisfactorily address the > issue I raised. Only comment I have is in section 2.1.3, "cause" should be > "causes". Thanks, will fix editorially. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html