Warm Connections

A warm connection to RTserver is a subset of a full connection to RTserver. A warm connection keeps as much RTserver-related information as possible. The only difference between a warm connection and a full connection is that the warm connection does not have a valid socket (that is, there is no communication link to RTserver with a warm connection). No messages can be flushed to RTserver on a warm connection and no messages can be read from the warm connection, but most functions behave in a fashion similar to when a full connection exists.

There are two types of warm connections:

New Warm Connections

A new warm connection is created when the RTclient creates a warm connection to RTserver. The RTserver is not aware of the RTclient when the RTclient has a warm connection. With a warm connection to RTserver, callbacks can be created, callbacks can be destroyed, and messages can be buffered, including messages sent without GMD. If RTclient has a warm connection and then creates a full connection (the connection changes from warm to full), the warm-buffered messages are flushed to the newly-created full connection. For more information, see the section on warm connections to RTserver in the TIBCO SmartSockets User’s Guide.

Creating a New Warm Connection

To create a warm connection to RTserver, use TipcSvc.create with the argument set to CONN_WARM. Here is a simple example that sets the ss.server_auto_connect option to FALSE, creates a warm connection, subscribes to subjects, and then creates a full connection. The RTclient subscribes to subjects /subj0 to /subj99, but only establishes the full connection after it is done subscribing:

/*------------------------java example----------------------------- 
 
import com.smartsockets.*; 
 
public class test { 
  test() { 
    TipcSrv srv = null; 
    int i; 
    try { 
      /* 
       * set the server_auto_connect option to false so 
       * client does not automatically try and create 
       * a connection when it calls any of the srv methods. 
       */ 
      Tut.setOption("ss.server_auto_connect", "false"); 
 
       /* 
       * get a srv object 
       */ 
      srv = TipcSvc.getSrv(); 
 
       /* 
       * create a warm connection 
       */ 
      srv.create(TipcSrv.CONN_WARM); 
 
       /* 
       * subscribe to all the subjects 
       */ 
      for (i=0; i<100; i++) { 
        String sub = "/subj" + i; 
        System.out.println("subscribing to = " + sub); 
        srv.setSubjectSubscribe(sub, true); 
      } 
 
      /* 
       * create a full connection 
       */ 
      srv.create(); 
      } 
      catch (TipcException e) { 
        e.printStackTrace(); 
      } 
   } 
 
   public static void main(String args[]) { 
     test client = new test(); 
   } 
} 

You can use TipcSvc.destroy to destroy warm connections. For more information on creating and destroying warm connections, look up TipcSvc in the Java API reference, provided online in Javadoc format.

Connections with Warm RTclients

A warm connection with a warm RTclient starts out as a full connection, and becomes a warm connection when the full connection is lost or destroyed. This type of warm connection is used only for GMD. With a warm RTclient, the RTserver remembers the name of the RTclient and the subjects to which the RTclient was subscribing when that RTclient disconnected. RTserver tracks the GMD messages that this warm RTclient should receive and acknowledge. RTserver does not buffer any non-GMD messages for the RTclient.

RTclient informs RTserver to keep warm RTclient information for itself by setting the ss.server_disconnect_mode option to warm before creating or destroying a full connection (the value of ss.server_disconnect_mode is sent to RTserver at those times). In this warm mode, if an RTclient disconnects for any reason (crashes or simply calls TipcSrvDestroy), all necessary RTservers (those with direct GMD publishing RTclients) keep warm RTclient information.

The warm RTclient is not associated with any RTserver, and it can later reconnect to any RTserver in the same multiple RTserver group. Until the warm RTclient reconnects or the timeout specified in the RTserver option Client_Reconnect_Timeout is reached, each RTserver continues to buffer GMD messages sent by its own direct RTclients that have a destination subject being subscribed to by the warm RTclient. If the warm RTclient reconnects in time, then all RTservers resend the proper GMD messages to the reconnected RTclient in the proper order. RTclient can even switch from one RTserver to another, and the RTserver takes care of all the necessary rerouting for GMD.

For more information on warm RTclients, see the section on warm RTclient in RTserver in the TIBCO SmartSockets User’s Guide.

Creating a Warm RTclient

You do not create a warm connection with a warm RTclient. Instead, you configure a warm RTclient by setting the value for the ss.server_disconnect_mode option to warm. Then, when the full connection from that RTclient to an RTserver is disconnected, it changes to a warm connection automatically. For more information on setting the option, see Configuring GMD on page 170.