Problem:

• Product Name: BES AppServer
• Product Version: 5.2.1
• Product Component: QoS Policies
• Platform/OS Version: All

When a client binds to a server using osagent, and make an oneway call, and if prior to the oneway call, the server restarts, the oneway call would fail, but the client would not rebind to the server. How to cause the client to rebind to the restarted server in this scenario?

Resolution:

The answer is to use SYNC_WITH_SERVER QoS policy. Please see the documentation (under Visibroker Programmer"s Reference, "Qualify of Service Interfaces and classes" section, and "SyncScopePolicy" subsection). The following are the possible values.

SYNC_NONE

The VisiBroker ORB returns control to the client (e.g. returns from the method invocation) before passing the request message to the transport protocol. The client is guaranteed not to block. Since no reply is returned from the server, no location-forwarding can be done with this level of synchronization.

SYNC_WITH_SERVER

The server-side VisiBroker ORB is to send a reply before invoking the target implementation. If a reply of NO_EXCEPTION is sent, any necessary location-forwarding has already occurred. Upon receipt of this reply, the client-side VisiBroker ORB shall return control to the client application. The client blocks until all location-forwarding has been completed. For a server using a POA, the reply would be sent after invoking any ServantManager, but before delivering the request to the target Servant.

SYNC_WITH_TARGET

Equivalent to a synchronous, non-oneway operation in CORBA 2.2. The server-side VisiBroker ORB will only send the reply message after the target has completed the invoked operation. Note that any LOCATION_FORWARD reply will already have been sent prior to invoking the target and that a SYSTEM_EXCEPTION reply may be sent at anytime (depending on the semantics of the exception). Even though it was declared oneway, the operation actually behaves like a synchronous operation. This form of synchronization guarantees that the client knows that the target has seen and acted upon a request. As with CORBA 2.2, only with this highest level of synchronization can the OTS be used. Any operations invoked with lesser synchronization precludes the target from participating in the client"s current transaction.

With both SYNC_WITH_SERVER, and SYNC_WITH_TARGET, an failed oneway call to a restarted server can cause the client to rebind. However both settings have the side-effect of some duration of blocking in the client calling thread, with SYNC_WITH_SERVER provides less amount of blocking time than SYNC_WITH_TARGET. Here is a sample client application that uses this QoS policy:

...
//(bindManager is the stub to the server object)
bindManager = BindManagerHelper.bind(orb, "/" _name "_poa", _name.getBytes(), null, bindOptions);
System.out.println("Bound to Bind manager at " new java.util.Date() "...");

 if(bindManager == null)
 {
System.out.println("Error binding to Bind manager at " new java.util.Date() "...");
 }
 }

 ////////////////////////
 short syncScope = org.omg.Messaging.SYNC_WITH_SERVER.value;
org.omg.CORBA.Any policyValue= orb.create_any();
org.omg.Messaging.SyncScopeHelper.insert(policyValue,syncScope);
org.omg.CORBA.Policy policies = null;
 try {
 policies =
orb.create_policy(org.omg.Messaging.SYNC_SCOPE_POLICY_TYPE.value,
policyValue);
 }
 catch (PolicyError ex) {
ex.printStackTrace();
 }

PolicyManager orbManager = null;
 try {
orbManager =
org.omg.CORBA.PolicyManagerHelper.narrow(orb.
resolve_initial_references(
 "ORBPolicyManager"));
 }
 catch (InvalidName ex1) {
 ex1.printStackTrace();
 }
 // Install the policy at the orb level.
 try {
orbManager.set_policy_overrides(new org.omg.CORBA.Policy[] {
 policies}
 ,
org.omg.CORBA.SetOverrideType.
 SET_OVERRIDE);
 }
 catch (InvalidPolicies ex2) {
 ex2.printStackTrace();
 }

 //QoS Policy is installed on the ORB, make the oneway call now.
bindManager.processName(name);