Connection Configuration Parameters
| Parameter | Default | Description |
|---|---|---|
| Verify_SSL_Certificate | no | Directs the pdbctl Utility to verify the IP address or hostname against the Subject Common Name (CN) or the Subject Alternative Name (SAN) in the server certificate presented by the Key Manager during authentication. To use this parameter, SSL must be configured. Possible settings: — yes: Enables this feature. — no: Disables this feature. |
| SSL_Handshake_Timeout | no default | Allocates time for the SSL handshake. SSL must be configured to use this feature. Set to any positive integer. |
| Use_Persistent_Connections | yes | Enables the persistent connections functionality. Possible settings: — yes: Enables the feature. The client persists the connections. — no: Disables the feature. A new connection is made for each connection request. The connection is closed as soon as the client receives the server response. |
| Size_of_Connection_Pool | 300 | The total number of client-server connections that your configuration could allow. Set to any positive integer. |
| Load_Balancing_Algorithm | round-robin | The algorithm used to determine how the client selects a Key Manager from a load balancing group. — round-robin: directs the connection to the next server in the load balancing group. — random: directs the connection to a randomly selected member of the load balancing group. |
| Connection_Idle_Timeout | 600000ms (10 min) | Specifies how long a connection can remain idle in the connection pool before the client closes it. Set it to any positive integer. |
| Unreachable_Server_Retry_Period | 60000ms | Specifies how long a client can attempt to establish a connection to a load-balancing group. After this period, if none of the servers in the load balancing group is reachable, an error is returned. If logging is enabled, error messages are written to the log file. Possible settings: — -1: This is the infinite retry interval. The client keeps trying to connect to a server until a connection is established. This setting is not compatible with multi-tier load balancing because the load balancer will never switch tiers. — 0: If multi-tier load balancing is enabled and Unreachable_Server_Retry_Period is set to 0, the client will not try to connect to a server on the particular load balancer in case all the servers are down in that particular load balancer. The client will move on to the next load balancer, if available, to establish connection.— A positive integer: If multi-tier load balancing is enabled then set this value between 1 and twice the value of the Connection_Retry_Interval. |
| Maximum_Server_Retry_Period | Specifies how long a client will try to connect to any of the servers on any tier. This parameter should only be set if multi-tiered load balancing is enabled. Possible settings: — -1: The connection manager will try every server on every tier until successful. — 0: Disables the feature; there is no overall limit. — A positive value: The connection manager will try to make connections for at least the duration set in Maximum_Server_Retry_Period and will return an error if no connection can be made on the tier in use when the try period expires. | |
| Connection_Timeout | 1m | Specifies how long the client will wait for the connection call to return a value. If a connection cannot be established before the timeout expires, the server is marked as down and is taken out of rotation until the Connection_Retry_Interval has passed.— 1m: The client will wait 1 minute. — 0: The client will not force a timeout. The waiting period set by the client’s OS still applies; the client will wait as long as the TCP stack normally waits for a connection. — Any positive integer: You can use abbreviations (ms, s, m, h, d) to specify the time units (milliseconds, seconds, minutes, hours, days). If you do not include an abbreviation, the default time unit (milliseconds) is used. If your application is time-sensitive, set this parameter a few hundred milliseconds less than your OS’s connection timeout. This will make connections to a down server fail more quickly, in which case failover will occur sooner. |
| Connection_Read_Timeout | 7000ms | Controls how long the client waits when reading data from a Key Manager before determining that it is down. Requests should only time out if the Key Manager is physically down (e.g. powered off, or not responding because of misconfiguration). The purpose of this parameter is to control how you want the client to react when the Key Manager is down. If you want it to time out eventually and return an error back to your application, then you should set this value to an appropriate number of milliseconds to allow for requests to complete in high load and high latency situations. Possible setting: — 0: Disables this setting. The client waits indefinitely until the Key Manager can be reached. Requests remain outstanding until the client’s request is successfully satisfied. — Any positive integer |
| Connection_Retry_Interval | 600000ms (10 min) | Specifies how long the client waits before trying to reconnect to a disabled server. If one of the Key Managers in a load balanced configuration is not reachable, the client assumes that the server is down, and then waits for the specified time period before trying to connect to it again. If the server or network is under a high load, a connection timeout could occur for a running sever. If your Connection_Retry_Interval is not long enough, another connection attempt will be made to the busy server-adding to its already high load. Possible setting: — 0: This is the infinite retry interval. The disabled server will never be brought back into use. — Any positive integer |
| Cluster_Synchronization_Delay | 170s | Specifies how long a client will wait before assuming that key changes have been synchronized throughout a cluster. After creating, cloning, importing, or modifying a key, the client will continue to use the same Key Manager appliance until the end of this delay period. For example, the client sets Cluster_Synchronization_Delay to 170s and sends a key creation request to appliance A, which is part of a cluster. Appliance A creates the key and automatically synchronizes with rest of the cluster. The client will use only appliance A for 170 seconds - enough time for the cluster synchronization to complete. After this time period, the client will use other cluster members as before.Possible settings: — 0: disables the function. — Any positive integer |
