-
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