Connection Configuration Parameters
| Parameter | Default | Description |
|---|---|---|
| Verify_SSL_Certificate | no | Directs CT-V 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. SSL must be configured to use this feature. Possible settings: — yes: Enables the feature. The server certificate must include either the hostname or the IP address in the CN or SAN field. If the hostname is used, the hostname must be reachable by the client. — no: Disables the feature. The Verify_SSL_Certificate parameter does not work with Java 17. |
| SSL_Handshake_Timeout | 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. Set to either yes or no. — yes - Enables the feature. The client persists the connections established with the Key Manager. — 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 possibly allow. (Not what actually exists at a given moment.) Set to any positive integer.Connections in the pool can be active or waiting, TCP or SSL. A connection is created as needed, and the pool scales as needed. The pool starts at size 0, and can grow to the value set here. Once the pool is full, new connection requests must wait for an existing connection to close. Connection pooling is configured for a client session on per server basis. The size of the pool applies to each client-session for a server, it is not a total value for a Key Manager or for a load balancing group. Regardless of your setting, the pool will always have at least 2 connections per NAE Server. The larger your connection pool, the less likely your client will get a failed connection request. |
| Load_Balancing_Algorithm | round-robin | The algorithm used to determine how the client selects a Key Manager from a load balancing group. Possible Settings: mdash 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) | The amount of time connections in the connection pool can remain idle before the client closes them. Set to any positive integer. |
| Unreachable_Server_Retry_Period | 60000ms | The amount of time the client will spend attempting to establish a connection to a load balancing group. An error is returned after the specified period if no server in the group is reachable. If logging is enabled, error messages are written to the log file. Set to -1 or to any positive integer. — -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 | The total amount of time that the client will spend trying to make connections to any server on any tier. This value is only used when multi-tiered load balancing is enabled. Set to -1, 0, or any positive integer. — -1: The connection manager will try every server on every tier until one answers. — 0: The feature is disabled; 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 | How long the client will wait for the connection call to return a value. If a connection cannot be established before the timeout expires, then the server is marked as down and is taken out of rotation until the Connection_Retry_Interval has passed. Possible Settings: — 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). Set to 0 or any positive integer. — 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 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. |
| Connection_Retry_Interval | 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. Possible settings: — 0: This is the infinite retry interval. The disabled server will never be brought back into use. — Any positive integer 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. | |
| Cluster_Synchronization_Delay | 170s | How long the 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. Set to either 0 or any positive integer. — 0: Disables the functionality. — Any positive integer You may want a higher setting for large clusters. |
