Issue 2120: Suspension of connections (notif_service-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: This issue relates to the ability provided in Notification Service ProxyPushSuppliers for a consumer to suspend a connection to the channel (stop the channel pushing events to it) which is unavailable to the other passive clients of the service - pull suppliers. The problem arises because, without the ability for a pull supplier to suspend a connection, its only choices are (a) to block the return of a pull() call until it is able to supply an event - resulting in some ORB-dependent timeout on the call, or a blocked thread in the channel. (b) to reply to many unnecessary try_pull() calls with a FALSE result - expecting that the channel will use some sort of backoff algorithm. (c) to disconnect from the proxy and obtain a new one when it is ready to supply events again - causing significant overhead for both itself and the channel. I suspect that we only provided one set of suspend/resume operations because the only circumatance we considered in the design was data overrun at consumer clients. We ignored the traditional symmetry, and neglected "under-run" and its less disasterous, but still significant problems. Resolution: Revised Text: Actions taken: October 27, 1998: received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: To: issues@omg.org Cc: notif_service-rtf@omg.org Reply-to: notif_service-rtf@omg.org Subject: Suspension of connections X-face: *A\_v+D,~Jx_g]`m,s61-x|*;H4hgZeE= Hi all, This issue relates to the ability provided in Notification Service ProxyPushSuppliers for a consumer to suspend a connection to the channel (stop the channel pushing events to it) which is unavailable to the other passive clients of the service - pull suppliers. The problem arises because, without the ability for a pull supplier to suspend a connection, its only choices are (a) to block the return of a pull() call until it is able to supply an event - resulting in some ORB-dependent timeout on the call, or a blocked thread in the channel. (b) to reply to many unnecessary try_pull() calls with a FALSE result - expecting that the channel will use some sort of backoff algorithm. (c) to disconnect from the proxy and obtain a new one when it is ready to supply events again - causing significant overhead for both itself and the channel. >From the channel's point of view it is far preferable to allow a supplier to suspend a connection when it knows it cannot provide any events, rather than having long outstanding pull calls consuming a potentially shared thread and handling ORB timeouts. I suspect that we only provided one set of suspend/resume operations because the only circumatance we considered in the design was data overrun at consumer clients. We ignored the traditional symmetry, and neglected "under-run" and its less disasterous, but still significant problems. Proposed Solution: We add the operations void suspend_connection() raises(ConnectionAlreadyInactive); void resume_connection() raises(ConnectionAlreadyActive); to all the interfaces *ProxyPullConsumer in the CosNotifyChannelAdmin module. Procedurally I think if a very broad consensus can be achieved rather quickly in the RTF (we could phrase it as a voting item with the usual quorum/majority rules), and Mike can make _yet another_ edit to the document, this can be included in the current RTF - with significant benefit to users (and system builders).... K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) General Purpose South, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: From: "Michael J. Greenberg" Subject: Re: Suspension of connections To: notif_service-rtf@omg.org Date: Tue, 27 Oct 1998 09:29:21 -0500 (EST) Cc: issues@omg.org Keith, First off, I agree with your proposal. The only question is, is it possible to incorporate this change into the revised document, and still get the changes approved at the upcoming meeting. The way I see it, there are the following choices: 1) Don't accept any more change requests, including this one, and try to get the current changes adopted at the upcoming meeting. This will allow OMG to publish the revised spec in the near term. In addition, at the upcoming meeting we will make a motion to charter a new RTF, which would address this issue along with any other new issues that are raised from this point on. 2) Do not attempt to get the current set of changes approved until the January meeting (the deadline for the output of this RTF is actually in mid-December, but keeping things open until that deadline would result in no changes being formally adopted until the January meeting...meaning the OMG will have to further postpone publishing Notification). 3) Attempt to secure enough votes on this issue prior to the Burlingame meeting, and still push to get the revised document adopted at that meeting. The problem with this is that it's rather painful getting enough people to cast their votes on a timely basis (I really wish that those people who were not really interested in participating in this RTF had not insisted on being members ;-<). If we go with 3), we have also discovered an issue with all of the suspend_connection/resume_connection operations that we would like to try to resolve along with Keith's resolution. We believe there should be an exception defined on all "suspend_connection/resume_connection" operations to cover the case in which the target Proxy is not currently connected to a client (e.g., ConnectionNotActive). Currently, it's possible for a client to invoke "suspend_connection" or "resume_connection" on a Proxy before a client has even connected to the Proxy, yet there is no appropriate exception to raise. I'm interested in opinions regarding choices 1), 2), or 3) above. Regards, Mike >>Hi all, >> >>This issue relates to the ability provided in Notification Service >>ProxyPushSuppliers for a consumer to suspend a connection to the channel >>(stop the channel pushing events to it) which is unavailable to the >>other passive clients of the service - pull suppliers. >> >>The problem arises because, without the ability for a pull supplier to >>suspend a connection, its only choices are >> >> (a) to block the return of a pull() call until it is able to >> supply an event - resulting in some ORB-dependent timeout on >> the call, or a blocked thread in the channel. >> >> (b) to reply to many unnecessary try_pull() calls with a FALSE >> result - expecting that the channel will use some sort of >> backoff algorithm. >> >> (c) to disconnect from the proxy and obtain a new one when it is >> ready to supply events again - causing significant overhead >> for both itself and the channel. >> >>>From the channel's point of view it is far preferable to allow a >>supplier to suspend a connection when it knows it cannot provide any >>events, rather than having long outstanding pull calls consuming a >>potentially shared thread and handling ORB timeouts. >> >>I suspect that we only provided one set of suspend/resume operations >>because the only circumatance we considered in the design was data >>overrun at consumer clients. We ignored the traditional symmetry, and >>neglected "under-run" and its less disasterous, but still significant >>problems. >> >>Proposed Solution: >> >>We add the operations >> >> void suspend_connection() >> raises(ConnectionAlreadyInactive); >> >> void resume_connection() >> raises(ConnectionAlreadyActive); >> >>to all the interfaces *ProxyPullConsumer in the CosNotifyChannelAdmin >>module. >> >>Procedurally I think if a very broad consensus can be achieved rather >>quickly in the RTF (we could phrase it as a voting item with the usual >>quorum/majority rules), and Mike can make _yet another_ edit to the >>document, this can be included in the current RTF - with significant >>benefit to users (and system builders).... >> >>K >>-- >>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >>Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud >> CRC for Distributed Systems Technology (DSTC) >> General Purpose South, University of Queensland, 4072, Australia >> ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 >>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >> 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >> >>> http://www.wiley.com/compbooks/vogel <<< >>::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >> -- Michael J. Greenberg NEC Systems Lab. 4 Independence Way Tel. 609-734-6142 Princeton, NJ 08540 Fax. 609-734-6001 mjg@syl.nj.nec.com