List of all configurable server parameters: ​

This section provides an in-depth explanation of each of the parameters in the TSF server configuration file. Many of these parameters are optional and have built-in default values. There is a good chance that the default values for a lot of these parameters will be sufficient for your needs, however they are all configurable -- for more information on how to override certain parameters, click here.

services ​

Default: None (Required only if dynamicServices is not provided)

List of services that this TSF instance is executing. Each service has the following sub-parameters:

name

This value must be specified and is the identifier you will use when communicating with your Service from your connected client code OR from another Service executing within the TSF Grid. When you sendSyncMsg(), sendAsyncMsg(), subscribe(), etc., the first parameter is always the name of your Service that you are communicating with.

executorClass

This value must be specified and is the name of your java class that implements the ServiceCommandResponseCommunicator interface that enables the TSF to execute your code as a Service. Please see Server Services page for an example of how to write this Service.

runAsSeparateServiceOnEachInstance

This value is optional, and defaults to false. If false, a Service of the same name (see "name" paremter above) is started on all TSF Instances (if there is no runsOn parameter) or on all those TSF Instances identified in the "runsOn" parameter. If true, then, in ascending order, a separately named Service using name as the base and with an underscore and a sequential number will be started on each of the TSF Instances. If, for example, this value were true for "name": "EchoService" as defined in the snippet of code above, then "EchoService_1" would execute on TSF:12; "EchoService_2" on TSF:13, "EchoService_3" on TSF:24 and "EchoService_4" on TSF:25 rather than "EchoService" executing on all 4 of these TSF Instances. The advantage of 'false' is: When one of your clients directs a request to "EchoService" it will be directed to the "least expensive" TSF Instance executing the "EchoService" (from a NetworkModel perspective) (or to a randomly selected "EchoService" among the "least expensive"). One advantage of using 'true' is when different instances of your same Service are used to Service different types of information and it is your external code that directs requests to a differently named instance of each Service.

configFile

This value is optional and has no default value. If your Service needs a path and file name of a configuration file with values it needs to execute, this is how you will pass it to your Service. The contents and format of this file depends on your Service.

dynamicServices ​

List of dynamic services that this TSF instance supports. Dynamic Services have the same sub-properties as services, EXCEPT for runAsSeparateServiceOnEachInstance -- dynamic services can never run as a separate service on each instance.

Default: None (Required only if services is not provided)

region, dataCenter, edges ​

These parameters depend on the network model type of the grid that the TSF instance is being added to. If you are using the default network model, you do not have to worry about configuring these parameters. If you wish to explore different types of network models, these parameters will be essential, and are explained here.

networkServiceEndpoints ​

This parameter is used to connect the TSF server to the Network Service, which serves as the main communication system within the TSF grid. More information on the network service and how to set it up / configure it for clients is explained here.

Default: None (Required)

instanceOverride ​

This parameter relates to changing the weight of connections to this particular TSF instance. An example of a use case for this is if a TSF server is running on a weaker machine, so you may want to increase the weight on its connections to give it less priority when figuring out the path for sending a particular message through the grid.

Has the following sub-properties:

overrideType

override

Ex.

"instanceOverride": {
  "overrideType": "MULTIPLICATIVE",
  "override": 3
}

For an in-depth look at how to further configure your overrides, see here.

Default: None (Optional)

internalClientConfig ​

This parameter (along with its sub-parameters) are for configurations related to establishing connections between TSF instances in the grid.

Has the following sub-properties:

numOfResponseProcessingThreads

See here for this parameter as defined for the client's SuperMainClientCmpnt -- this parameter is the same except it is configured for the SuperMainClientCmpnt of the server's inter service router when communicating with other instances in the grid.

Default value is 9.

numOfAttemptsToReconnect

Default value is 3. This parameter is the number of attempts to reconnect to another TSF instance in the grid if socket connection is lost. If this value is 0, this means that after a lost connection this instance will not attempt to reconnect and will immediately report the other TSF instance as failed.

numMillisToWaitBetweenReconnectAttempts

Default value is 2000 (e.g. 2 seconds). This parameter is the number of milliseconds to wait between attempts to reconnect with another TSF instance in the grid after connection is lost. This value applies to the second and subsequent reconnect attempts.

maxSendQueueDataSize -> here

maxReceiveQueueDataSize -> here

maxSendQueueSize -> here

maxReceiveQueueSize -> here

sendPingRequestEveryMillis -> here

receivePingRequestEveryMillis -> here

instanceInitDependencies ​

List of other TSF instances in the grid that this one is dependent on before it can start up. Ex. If TSF instance 1 configures that its instanceInitDependencies are [2, 3, 4], it will not initialize its services until TSF instances 2, 3, 4 have their services initialized.

Default: None (Optional)

insecurePort ​

The insecure port used by client code to connect. Using an insecure port is good from a performance perspective when connections are within the organization.

Default: 9080

securePort ​

This is the secure port that is used for (and requires) a 2-way authenticated SSL connection (not the typical 1-way authentication where connecting client is assured that the server is who they think it is). This requires the connecting client to have access to a keystore with public and private key.

Default: 10443

interConnectPort ​

The port that servers within the TSF Grid use to communicate with each other.

Default: 9090

gridInitializationTimeout ​

After this time, the Register Service will force all TSF Instance that are waiting to complete initialization to shut down (because at least some machines have not come up or been marked as down in this allotted timeframe). This parameter is only used during startup of the entire grid.

Default: 900000 (This setting is in milliseconds, so 15 mins = 1,000 X 60 x 15 = 900000)

maxServerConnCmpntThreads ​

One particular value that you might want to specify differently across sets of individual TSF Instances (i.e., in teir 3 -- "instanceConfig") is the "maxServerConnCmpntThreads" as this is the maximum number of simultaneous connections (i.e., clients) that can connect to a particular TSF Instance. The default is 20 -- probably too low except for machines in your grid with only a few cores. This will depend on network bandwidth to particular machines and the number of cores that different servers have.

Default: 20

maxBackLogConnectionsQueued ​

If more than "maxNumOfExternalConnections" set for a TSF Instance attempt to connect to said particular TSF Instance, these will queue until a ServerConnectionCmpnt is freed by a client disconnecting. However, this is the size of said queue and, if more than this many incoming connections are waiting to connect, a QueueFullException will be thrown.

Default: 20

numProcessThreadsPerConnectionThrd ​

For each external connection, this setting determines the number of processes that can be executed by the TSF's threads simultaneously (i.e., that are dedicated to servicing that connection). E.g., if the external connected client was a Trader workstation, a thread could always be available for handling end user commands (e.g., when end user placed or cancelled a trade order), while another thread could be used to subscribe to the marketDataService for all items in that end user's view, while still a third thread could execute a risk report on behalf of that end user in the background. If these three ConnectionProcessing threads are working on requests and new requests are sent, these will be queued until one of these processing threads is available. If some of your Services do not spawn their own threads and involve long-running processes, you might want to increase this number. As the TSF enables asynchronous commands to be sent, it must be noted that, though unlikely, 2 asynchronous commands sent could be processed out of order if this value is > 1.

Default: 3

isSignatureServiceEnabled ​

When true, all signed messages coming from client code will automatically be verified before passing the request to your Service AND signed messages and their digital signatures will automatically be stored for non-repudiation purposes.

Default: false

shouldFailWhenNotMajorityOfSplitBrainGrid ​

This parameter configures what the TSF instance's behavior should be when faced with a split brain situation in the grid when it is NOT in the majority of the split. For a more clear understanding of this parameter, take the following example: Let's say we have a grid of 60 machines -- it starts with the property that every server in the grid can get to every other server in the grid (either through a direct connection, or indirectly through other servers). Suppose after 5 servers in the grid go down, this no longer is the case. With the remaining 55 instances in the grid, 40 of them are all connected with each other and can get to one an other, but the remaining 15 are isolated from the main grid, they become the 'smaller' grid where they can all get to each other, but not the 40 servers in the 'bigger' grid. This is the situation known as "Split brain". If in this situation, the servers in the 'bigger' grid remain up and functioning always. This property defines what to do about the servers that are NOT in the majority grid. If this property is set to 'true', then these servers will fail and shut themselves down if they identify that they are not in the 'bigger' grid. If this property is set to 'false', they will remain up and the grid will be split, until those failed instances come back.

Default: true

numProcessThreadsPerInterServiceConnectionThrd ​

Similar to "numOfProcessingThreadsPerExternalConnection" (which has a default of 3), These threads will be used to handle a request targeted at this TSF Instance that originated from another. For example all communication from TSF:17 to TSF:18 (if these 2 TSF Instances were directly connected), would come in to the ISRConnecton established from TSF:17 to TSF:18 when the TSF first started. 9 threads (by default) would be available to handle all such communication (which might be pass-through -- if TSF:18 were not the ultimate target) or might rely on one of these threads to execute your Service code on TSF:18. If some of your Services do not spawn their own threads and involve long-running processes, you might want to increase this number. (Note: If pass-through, these threads don't do much work as they place the message in other components of the TSF where these other components have their own threads that perform the sending.)

(This applies when an ISR is used, which is whenever communication originates from externally connected client code [from any TSF Instance] or from your Service that directly sends a synchronous or asynchronous message to a different instance of your Service or to a different Service. It does not apply when one Service communicates with another [or with another instance of itself] on its own behalf -- typically during startup. For that, the 2 parameters below apply and those likely will not need adjustment.)

Default: 9

TSFInstanceToRegSvcHeartbeatInMillis ​

Has a corresponding Register Service parameter. Refers to how often each TSF instance will send a heart beat to the Register Service while the grid is in the process of coming up, in order for the Register Service to know which instances have failed during the grid initialization process. This variable becomes meaningless once the TSF grid comes up -- because at that point each TSF instance is connected to other servers in the grid, and failures are detected through these connections being lost.

Default: 2500 milliseconds, or 2.5 seconds.

force ​

This parameter deals with the case of changing the configuration for a failed TSF instance in the grid. Once a TSF instance starts up and is added to the grid, its configuration file that it provides is saved. If a TSF instance in the grid fails, in order for it to be added back, the configuration that it provides when it comes up again must be identical to the one that was saved from earlier (for that TSF instance number), otherwise it will be rejected. However, if we want to change the configuration of a failed instance, the TSF instance should set this force flag, in which case when it comes back a second time this new configuration file will be used instead. Note: This parameter only has meaning if the instance number a TSF server is coming up with was failed previously, and the configurations file is different. If the configuration file provided is identical, the force flag is not needed, and the instance will automatically be added back. If the instance number is not in the network model, the force flag is not needed, and the instance is automatically added. If the instance number IS in the network model and NOT failed, then even if the force flag is used, the instance will not be added.

Default: false

internalServerConnCmpntConfig ​

This property refers to the configurations that configure the internal server connection components that are for connections between this TSF instance and other TSF instances in the grid.

Consists of the following sub-properties:

maxSendQueueDataSize -> here

maxReceiveQueueDataSize -> here

maxSendQueueSize -> here

maxReceiveQueueSize -> here

sendPingRequestEveryMillis -> here

receivePingRequestEveryMillis -> here

externalServerConnCmpntConfig ​

This property refers to the configurations that configure the external server connection components that are for connections between this TSF instance and external clients to the grid.

Consists of the same sub-properties (with the same default values) mentioned for internalServerConnCmpntConfig.