Issue 9743: Stub_receive_other Paragraph 2 (qos4ccm-ftf) Source: Fraunhofer FOKUS (Mr. Tom Ritter, ritter@fokus.fraunhofer.de tom@users.berlios.de) Nature: Clarification Severity: Significant Summary: Stub_receive_other Paragraph 2, which discusses retries, does not seem to be consistent with the approach of implementing these intercept points by wrapping the ORB-level stub. ORB-level retries would be transparent to the wrapper, and wrapper-level retries would appear to the ORB as independent requests. I don't see how the wrapper could ensure that the PortableInterceptor::Current remains the same, except that the same thread is presumably used. Resolution: closed no change Revised Text: Actions taken: May 18, 2006: received issue January 15, 2008: closed issue' Discussion: Using the same thread is assumed, since container has still the control on this call, it will ensure that the same thread is used for the retry. If not using the same thread an alternative implementation strategy is that the container makes sure that the new PortableInterceptor::Current contains the same content as the one of the preceding call. Disposition: Closed, no change End of Annotations:===== m: webmaster@omg.org Date: 18 May 2006 04:29:19 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Tom Ritter Company: Fraunhofer FOKUS mailFrom: ritter@fokus.fraunhofer.de Notification: Yes Specification: QoS4CCM Section: 8.5.3.4 FormalNumber: ptc/06-04-15 Version: final adopted RevisionDate: April/2006 Page: 24 Nature: Clarification Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 Description Stub_receive_other Paragraph 2, which discusses retries, does not seem to be consistent with the approach of implementing these intercept points by wrapping the ORB-level stub. ORB-level retries would be transparent to the wrapper, and wrapper-level retries would appear to the ORB as independent requests. I don't see how the wrapper could ensure that the PortableInterceptor::Current remains the same, except that the same thread is presumably used. Date: Tue, 21 Aug 2007 09:30:41 +0200 From: Tom Ritter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) To: qos4ccm-ftf@omg.org Subject: proposed solution fo issue 9743 X-OriginalArrivalTime: 21 Aug 2007 07:30:33.0578 (UTC) FILETIME=[28CAA4A0:01C7E3C5] X-Fraunhofer-Email-Policy: accepted Hi All, I would propose the to close issue 9743 and to give the following explanatory text: Yes using the same thread is assumed, since container has still the control on this call, it will ensure that the same thread is used for the retry. If not using the same thread an alternative implementation strategy is that the container makes sure that the new PortabelInterceptor::Current contains the same content as the one of the preceding call. Please reply if you have any comment on this proposed resolution. Cheers, Tom -- Tom Ritter Head of Working Area Model-Driven Engineering Fraunhofer FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin, Germany +49 30 3463 - 7278 (fon), - 8000 (fax) mailto:ritter@fokus.fraunhofer.de