- 
                            Key: CORBA3-20
- 
                            Legacy Issue Number: 3947
- 
                            Status: closed
- 
                            Source: Progress Software ( Eoghan Glynn)
- 
                            Summary:I'd like to raise an issue and garner feedback on the interaction of the 
 Messaging timeout QoS policies (or indeed any proprietary invocation
 timeout mechanism) and portable interceptors.Where a bound is being imposed on request and/or reply delivery, and 
 portable interceptors are present in the client- and/or server-side
 binding, these interceptors surely must be made aware of the relevant
 timeout(s) so that they may bound any potentially blocking activities
 they engage in. Assuming that it would be unacceptable to dictate that
 potentially blocking activity (such as making a subsidiary invocation)
 may not be undertaken in interception point operations, it appears some
 addition to the PortableInterceptor::RequestInfo interface is required
 to facilitate the Messaging timeout policies at least. For instance, the
 absolute request and reply expiry times could be passed as additional
 attributes:module PortableInterceptor { // ... readonly attribute TimeBase::UtcT request_end_time; readonly attribute TimeBase::UtcT reply_end_time; }
 {
 interface RequestInfo
 ; 
 };the former bounding the send_request, send_poll, 
 receive_request_service_contexts and receive_request interception points
 and the latter bounding the send_reply, send_exception, send_other,
 receive_reply, receive_exception and receive_other interception points.
 Of course this all relies on the discipline of the portable interceptor
 implementor, i.e. that they do not ignore the constraints imposed by the
 timeouts.
- 
                            Reported: CORBA 2.4 — Thu, 12 Oct 2000 04:00 GMT
- 
                            Disposition: Resolved — CORBA 3.0.2
- 
                            Disposition Summary:close no change 
- 
                            Updated: Fri, 6 Mar 2015 20:58 GMT