The following table contains a description of the configuration properties that may be set in SGC.properties
:
Property | What it specifies | Default |
---|---|---|
|
enables or disables the heartbeat timeout mechanism in the SGC. If this is enabled in the SGC then the TCAP stack must also be configured to send heartbeats, otherwise the connection between the TCAP stack and SGC will be marked as timed out after |
|
|
timeout (in seconds) waiting for a handshake between the SGC and TCAP stack |
|
|
how many seconds to wait before the Peer closes the connection after not receiving anything Value must be greater than the heartbeat period configured in the TCAP stack, see Data Connection Heartbeat Mechanism for details. |
|
|
capacity of the Peer sending queue |
|
|
whether to disable the Nagle algorithm for the connection between the SGC and TCAP stack |
|
|
whether to ignore the configured switch-local-address when establishing a client intra-cluster-communication (comm switch module) connection;
if
|
|
|
whether to disable the Nagle algorithm in intra-cluster communication client mode (comm switch module) |
|
|
number of threads serving connections (client mode) from other SGC nodes; for intra-cluster communication (comm switch module) Each thread requires three File Descriptors. The recommended value should be one less than number of nodes in the cluster. |
|
|
number of threads accepting connections from other SGC nodes; for intra-cluster communication (comm switch module) Each thread requires three File Descriptors. |
|
|
whether to disable the Nagle algorithm in intra-cluster communication server mode (comm switch module) |
|
|
number of threads serving connections (server mode) from other SGC nodes; for intra-cluster communication (comm switch module) Each thread requires three File Descriptors. The recommended value should be one less than number of nodes in the cluster. |
|
|
size of the socket receive buffer (in bytes) used by intra-cluster communication (comm switch module) Use a value <= |
|
|
size of the socket send buffer (in bytes) used by intra-cluster communication (comm switch module) Use a value <= |
|
|
how long to wait, in milliseconds, after a configuration update has been made before the updated config is saved. This delay improves the speed of batched config imports. A value of |
|
|
number of threads accepting data connections from TCAP stack instances Each thread requires three File Descriptors. |
|
|
number of threads serving data connections from TCAP stack instances Each thread requires three File Descriptors. The recommended value should be equal to the number of TCAP stack instances served by the cluster. |
|
|
number of threads accepting connections from TCAP stack instances requesting balancing information |
|
|
number of threads serving accepted connections from TCAP stack instances requesting balancing information |
|
|
whether to try a graceful shutdown first (value true) when shutting down because of a uncaught exception |
|
|
how long to wait (in milliseconds) during graceful shutdown, before forcing a shutdown |
|
|
whether an uncaught exception should result in instance shutdown (value Severe errors ( |
|
|
optional path to the Hazelcast config file |
none, but the default |
cluster group to which this instance belongs |
|
|
|
implementation of the alarming factory |
|
|
maximum alarming history age (in minutes) |
|
|
property name used to get the path where the SGC data file should be stored |
current working directory at the time of startup |
|
property name used to get the actual SGC data file name |
|
|
whether the SGC should ignore validation of the MD5 signature of the XML configuration file |
|
|
maximum number of inbound messages that may be processing or waiting to be processed |
|
|
how long (in seconds) the SGC should consider a connection pending after peer node allocation, but before actual connection (after this time, the SGC assumes that the connection will not happen) This value is used only by the Legacy 'ocss7.urlList' Connection Method to assist with balancing TCAP stacks amongst SGCs. If it is set too small then under certain failure conditions it may result in a TCAP stack continually trying to reconnect to an SGC data port that it cannot reach. The suggested value for this property is The default value allows for 13 TCAP stacks and 2 SGCs under worst case failure conditions with a 4 second safety factor. The safety factor allows for network latency and timer precision. |
|
|
maximum number of outbound messages that may be processing or waiting to be processed |
|
maximum number of concurrent transactions that this SGC may process The |
|
|
|
The path where the SGC upgrade packs are stored.
If the provided path is relative, then this is relative to |
|
|
maximum number of tasks (messages to be processed) in one worker queue |
|
|
number of threads used by the worker group to process inbound and outbound messages |
|
|
counter file name for snmp4j |
|
|
file name for snmp4j persistent storage |
|
|
Force the SGC to use the SNMP v3 username as configured instead of prefixing it with |
|
|
whether TCAP manager uses a Nagle algorithm for incoming connections |
|
name of the SGC instance within the cluster |
|