Connection Configuration Parameters
Parameter | Default | Description |
---|---|---|
Verify_SSL_Certificate | no | The Verify_SSL_Certificate parameter directs the 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. 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 feature is disabled by default. |
SSL_Handshake_Timeout | yes | The SSL_Handshake_Timeout parameter allocates time for the SSL handshake. SSL must be configured to use this feature. Set to any positive integer. |
Use_Persistent_Connections | yes | The Use_Persistent_Connections parameter enables the persistent connections functionality.Possible settings —yes – Enables the feature. The utility establishes persistent connections with the NAE Servers. This is the default value. —no – Disables the feature. A new connection is made for each connection request. The connection is closed as soon as the utility receives the server response. |
Size_of_Connection_Pool | 300 | The Size_of_Connection_Pool parameter specifies the total number of client-server connections that your configuration could possibly allow. (Not what actually exists at a given moment.)Possible setting: —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 on a per-client basis. The size of the pool applies to each utility; it is not a total value for a Key Manager or for a load balancing group. If there are multiple clients running on the same machine, separate connection pools are maintained for each client. |
Connection_Timeout | 60000ms | The Connection_Timeout parameter specifies how long the utility waits for the TCP connect function before timing out.Possible settings —0-Disables this setting. The utility uses the operating system’s connect timeout. —Any positive integer Setting this parameter a few hundred ms less than the operating system’s connection timeout makes connection attempts to a downed server fail faster, and failover happens sooner. If a connection cannot be made before the timeout expires, the server is marked as down and taken out of the rotation. Note: If your utility is working with many versions of a key, do not set the Connection_Timeout parameter too low. Otherwise, the utility connection may close before the operation is complete. |
Connection_Idle_Timeout | 600000ms | The Connection_Idle_Timeout parameter specifies the amount of time connections in the connection pool can remain idle before the client closes them.Possible setting —Any positive integer There are two different connection timeout values: one configured on the Key Manager and the other in the properties file. The value of the timeout in the properties file must be less than what is set on the server. This lets the client control when idle connections closed. Otherwise, the client can maintain a connection that is closed on the server side, which can lead to error. |
Unreachable_Server_Retry_Period | 60000ms | The Unreachable_Server_Retry_Period parameter specifies 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.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. —Any positive integer-If multi-tier load balancing is enabled then set this value between 1 and twice the value of the Connection_Retry_Interval parameter. |
Maximum_Server_Retry_Period | The Maximum_Server_Retry_Period parameter the total amount of time that the utility will spend trying to make connections to any server on any tier. This value is only used when multi-tiered load balancing is enabled.Possible settings —-1-The connection manager will try every server on every tier until one answers. —0-The feature is disabled; there is no overall limit. —Any 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_Retry_Interval | The Connection_Retry_Interval parameter determines how long the utility waits before trying to reconnect to a disabled server. If one of Key Manager servers in a load balanced configuration is not reachable, the utility 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. | |
Cluster_Synchronization_Delay | 170s | The Cluster_Synchronization_Delay parameter specifies how long the utility will wait before assuming that key changes have been synchronized throughout a cluster. After creating, cloning, importing, or modifying a key, the utility will continue to use the same Key Manager until the end of this delay period. Possible settings —0–Disables the function. —Any positive integer. For example, the utility sets Cluster_Synchronization_Delay to 100s 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 utility will use only appliance A for 100 seconds - enough time for the cluster synchronization to complete. After this time period, the utility will use other cluster members as before. |