Configuring GMD

To use the default configuration for GMD, you simply start using GMD, and the default values of the GMD-related options are used. Information on starting GMD is in Sending GMD Messages on page 176. When you start GMD using the default configuration, file-based GMD is activated if you had set a value for ss.unique_subject. If there was no value set for ss.unique_subject, memory-based GMD is activated.

If you want to configure GMD to use values other than the defaults, you can set the Java GMD-related options in the options database using the same techniques as for any other options. See Option (Property) Databases and Loading RTclient Options on page 136 for information on setting options.

Java GMD-Related Options

The Java options that affect GMD, listed in Table 4, are similar to the RTclient options for C described in the TIBCO SmartSockets User’s Guide. You might find it helpful to read the descriptions in that book for setting GMD-related options. Complete descriptions of the Java RTclient options are in Chapter 9, RTclient Options.

Table 4 Options Related to GMD
Option Name	Description
ss.ipc_gmd_directory	Specifies where the GMD files should be located.
ss.ipc_gmd_type	Specifies whether GMD is file-based or memory-based, which also determines where to create the GMD area (on disk or in memory)
ss.server_delivery_timeout	Controls the delivery timeout property of the connection to RTserver.
ss.server_disconnect_mode	Specifies the action RTserver should take when RTclient disconnects from RTserver.
ss.unique_subject	Specifying a unique_subject triggers file-based GMD.

Configuring File-Based GMD

To configure file-based GMD, you need to set some of the GMD-related options. For information on setting options, see Setting RTclient Options on page 137. Follow these steps for file-based GMD:

Step 1

You must set a value for the ss.unique_subject option, a value other than the default of _node_start-time. For more information, see ss.unique_subject on page 159.

Step 2

If the ss.ipc_gmd_type option is left at its default value of default, file-based GMD is attempted. For more information, see ss.ipc_gmd_directory on page 144.

Step 3

You can use the default settings for the ss.ipc_gmd_directory, ss.server_delivery_timeout, and ss.server_disconnect_mode options or set your own values. These options do not affect what type of GMD is attempted, file-based or memory-based. You can configure these options as you like for your system:

Set a value for the ss.server_delivery_timeout option or use the default value of 30 seconds.

You can change the value to give the sending process more or less time to wait for all receiving processes to acknowledge delivery of a guaranteed message. If you set the value to 0.0, this option is disabled, and the sending process never times out.

Set a value for the ss.server_disconnect_mode option or use the default value of gmd_failure.

The ss.server_disconnect_mode option specifies what the RTserver should do, if anything, if and when an RTclient disconnects from RTserver. The three possible values are:


`warm`	specifies that RTserver saves subject, project, and guaranteed message delivery information about the disconnecting RTclient so that no messages are lost.
`gmd_failure`	specifies that RTserver destroys all information about the disconnecting RTclient and causes pending guaranteed message delivery to fail.
`gmd_success`	specifies that RTserver destroys all information about the disconnecting RTclient, but causes pending guaranteed message delivery to succeed.

Notes on File-Based GMD

File-based GMD is only attempted if both are true:

the ss.unique_subject option is set to a value other than its default, and

the ss.ipc_gmd_type option is set to default

If ss.ipc_gmd_type is set to memory, memory-based GMD occurs even if you set a value for ss.unique_subject. However, if you did not set a value for ss.unique_subject, memory-based GMD is used even if ss.ipc_gmd_type is set to default.

When ss.unique_subject is set, and ss.ipc_gmd_type is default, SmartSockets attempts file-based GMD, but sometimes must revert to memory-based GMD. See Reverting to Memory-Based GMD on page 174.

Although you specify file-based GMD, memory-based GMD is used whenever file-based GMD is attempted but is unsuccessful. This provides a measure of safety, because even though file-based GMD might fail, your messages are still protected under GMD.

Configuring Memory-Based GMD

To configure memory-based GMD, you need to set some of the GMD-related options. For information on setting options, see Setting RTclient Options on page 137. Follow these steps for memory-based GMD:

Step 1

If the value is set to memory, memory-based GMD is used, even if ss.unique_subject is set. If left to its default value of default, file-based GMD is attempted. For more information, see ss.ipc_gmd_type on page 144.

Step 2

You can use the default settings for the options ss.unique_subject, ss.server_delivery_timeout, and ss.server_disconnect_mode, or set your own values:

Set a value for the ss.unique_subject option or use the default value.

If you need to specify a value for ss.unique_subject other than the default value, you can set ss.unique_subject and still get memory-based GMD if you set ss.ipc_gmd_type to memory.

Set a value for the ss.server_delivery_timeout option or use the default value of 30 seconds.

Set a value for the ss.server_disconnect_mode option or use the default value of gmd_failure.

The ss.server_disconnect_mode option specifies what the RTserver should do, if anything, if and when an RTclient disconnects from RTserver. The three possible values are:


`warm`	specifies that RTserver saves subject, project, and guaranteed message delivery information about the disconnecting RTclient so that no messages are lost.
`gmd_failure`	specifies that RTserver destroys all information about the disconnecting RTclient and causes pending guaranteed message delivery to fail.
`gmd_success`	specifies that RTserver destroys all information about the disconnecting RTclient, but causes pending guaranteed message delivery to succeed.

Reverting to Memory-Based GMD

When ss.unique_subject is set, and ss.ipc_gmd_type is set to default, SmartSockets attempts file-based GMD. If file-based GMD cannot be carried out, SmartSockets reverts to memory-based GMD for the message. Generally, when SmartSockets reverts from file-based to memory-based GMD, it is because the file-based GMD area could not be written to. If the disk files cannot be created or a security exception is thrown, Java displays a warning message to the console, and automatically switches to memory-based GMD.

A common example of this is a Java applet. Most Java applets cannot write to the local file system, where the GMD spool area resides for file-based GMD. If you specify file-based GMD, the applet attempts to write to the disk where the GMD area is located. A SecurityException is thrown, and SmartSockets reverts to memory-based GMD.