Product: OpenFusion JacORB

Version: ALL

Description:

How to dynamically set a timeout value and bypass the pending_reply_timeout property value for a given method call?

Resolution:

For each CORBA request four different points in time can be specified:

• Request Start Time: the time after which the request may be delivered to its target
• Request End Time: the time after which the request may no longer be delivered to its target
• Reply Start Time: the time after which the reply may be delivered to the client
• Reply End Time: the time after which the reply may no longer be delivered to the client

Each of these points in time can be specified on a per-object level as a client-side override policy: RequestStartTimePolicy, RequestEndTimePolicy, ReplyStartTimePolicy, and ReplyEndTimePolicy (see below for concrete code examples).

Each of these policies specifies an absolute time, which means that they will usually have to be set again for each individual request. As a convenience, there are two additional policies that allow you to specify a relative time for Request End Time and Reply End Time; they are called RelativeRequestTimeoutPolicy and RelativeRoundtripTimeoutPolicy, respectively. These timeouts are simply more convenient ways for expressing these two times; before each individual invocation, the ORB computes absolute times from them (measured from the start of the invocation at the client side) and handles them just as if an absolute Request End Time or Reply End Time had been specified.

We will therefore only discuss the four absolute timing policies below.
• As soon as the ORB receives control (prior to marshaling), it converts any RelativeRequestTimeoutPolicy or RelativeRoundtripTimeoutPolicy to an absolute value, by adding the relative value to the current system time.
• The ORB then checks whether Request End Time or Reply End Time have already elapsed. If so, no invocation is made, and an org.omg.CORBA.TIMEOUT is thrown to the client.
• After the ORB has sent the request, it waits for a reply until Reply End Time has elapsed. If it receives no reply before that, the request is discarded and an org.omg.CORBA.TIMEOUT thrown to the client. (JacORB does not currently cancel the outstanding request, it simply discards the reply, should one arrive after the timeout has elapsed.)1
• On the server side (before demarshaling), the ORB checks whether the Request End Time has already elapsed. If so, the request is not delivered to the target, and an org.omg.CORBA.TIMEOUT is thrown back to the client.
• Optionally, the server-side ORB may also check at this point whether the Reply End Time has already elapsed, and not actually invoke the target in this case (throwing back an org.omg.CORBA.TIMEOUT to the client as well). Since the Reply End Time would then be checked both on the client and the server side, this requires that the clocks on both machines are synchronized at least to the same order of magnitude as the timeout itself. This check is therefore off by default, and may be enabled by setting the property jacorb.poa.check reply end time to “on”.
• If the request proceeds, the ORB waits until the Request Start Time has been reached, if one was specified, and has not already elapsed. After that, the request is delivered to the target.
• After the target invocation has returned, the ORB may optionally check whether the Reply End Time has now elapsed. Similar to the check prior to the target invocation, this check is also optional and controlled by the property jacorb.poa.check reply end time (see discussion above). If the check is enabled, and the Reply End Time is found to have elapsed at this point, the ORB sends an org.omg.CORBA.TIMEOUT back to the client, rather than the actual reply.
• If the reply arrives at the client before Reply End Time has elapsed, the ORB waits until Reply Start Time has been reached, if one was specified, and has not already elapsed. After that, the reply is delivered back to the client. The bottom line of this is that for a simple, per-invocation timeout, you should specify a RelativeRoundtripTimeoutPolicy.

In CORBA, points of time are specified to an accuracy of 100 nanoseconds, using values of struct TimeBase::UtcT.

To allow easy manipulation of such values from Java, JacORB provides a number of static methods in org.jacorb.util.Time.

For example, to convert the current Java time into a UtcT value, write
UtcT currentTime = org.jacorb.util.Time.corbaTime();

To create a UtcT value that specifies a time n milliseconds in the future, you can write
UtcT time = org.jacorb.util.Time.corbaFuture (10000 * n);
(The argument to corbaFuture() is in CORBA time units of 100 ns; we multiply n by 10000 here to convert it from Java time units (milliseconds).)

The following shows how to set a timing policy for an object using the standard mechanism (see the beginning of this chapter for an explanation). In this example, we set a Reply End Time that lies one second in the future:

import org.omg.CORBA.*;
SomeCorbaType server = ...
// the object for which we want to set
// a timing policy
org.omg.CORBA.ORB orb = ...
org.omg.CORBA.Any a = orb.create_any();
org.omg.TimeBase.UtcT replyEndTime = org.jacorb.util.Time.corbaFuture (1000 * 10000);
// one second
org.omg.TimeBase.UtcTHelper.insert (a, replyEndTime);
try
  {
    Policy p = orb.create_policy (REPLY_END_TIME_POLICY_TYPE.value, a);
    server._set_policy_override (new Policy[]{ p }, SetOverrideType.ADD_OVERRIDE);
  } catch (PolicyError e) { ... }

Using the constructors of JacORB’s implementations of policy values, this becomes less verbose:

SomeCorbaType server = ...
Policy p = new org.jacorb.orb.policies.ReplyEndTimePolicy (org.jacorb.util.Time.corbaFuture (1000 * 10000));
server._set_policy_override (new Policy[]{ p }, SetOverrideType.ADD_OVERRIDE);

Likewise, to set a Relative Roundtrip Timeout of one second, write:

SomeCorbaType server = ...
Policy p = new org.jacorb.orb.policies.RelativeRoundtripTimeoutPolicy (1000 * 10000);
server._set_policy_override (new Policy[]{ p }, SetOverrideType.ADD_OVERRIDE);

The difference between this and the prior example, where a Reply End Time was used, is that the latter specifies a relative time to CORBA. The policy will therefore be valid for all subsequent invocations, because the absolute deadline will be recomputed before each invocation. In the first example, the deadline will no longer make sense for any subsequent invocations, since only an absolute time