Skip to content
On this page

List of all configurable client parameters:

Overview: There are 3 files that must be created to instantiate a TSFClient (i.e., a SuperMainExternalClientCmpnt) to connect to a grid of servers managed by the TSF:
--A .properties file: Contains the userName of the secure or insecure user; the ClientConfigFileName with the path and name of the .json file with all the parameters and properties for the connection/connection's behavior; and, a TokenFileNameAndPath with the path and file name of the "token" file containing at least the password for the userName, and, for a secureConnection, additionally, the password of the end user's TrustKeyStore and KeyKeyStore.
--A .json file: This file contains the configuration parameters that control the behavior of the TSFClient and its interaction with the TSF Grid of servers. Its values are discussed below.
--A "token" file: This file holds the password for the userName in the .properties file (necessary even for an insecure connection). If this is a secure connection, this file also holds the passwords of the TrustKeyStore and KeyKeyStore.

These are the properties that must be specified in a .json file (which could be named, e.g., TSFClient.json) in order to instantiate a SuperMainExternalClientCmpnt to connect to the TSF:

{
  "hostname": "localhost",
  "port": 9080,
  "SSLPort": 9081,
  "secureConnection": false,
  "sessionId": 0,
  "numOfAttemptsToReconnect": 3,
  "numMillisToWaitBetweenReconnectAttempts": 1000,
  "acceptNewSessionOnReconnect": true,
  "actionAfterFinalReconnectFails": "AttemptNewConnWithNewSession",
  "requestTimeoutInMillis": 3000,
  "numOfResponseProcessingThreads": 3,
  "autoVerifySignedMsgPkg": true,
  "sendSignedMsgPkg": true,
  "signatureAlgorithm": "SHA256withRSA",
  "connectionConfig": {
    "maxReceiveQueueSize": 10000,
    "maxReceiveQueueDataSize": 10000000, 
    "maxSendQueueSize": 10000,
    "maxSendQueueDataSize": 10000000,
    "sendPingRequestEveryMillis": 20000,
    "receivePingRequestEveryMillis": 50000
  },
  "queueFullRetryIntervalInMillisForReceptionCmpnt": 2000
  "numRetryAttemptsOnQueueFullReceptionCmpnt": 3
  "keyStoreName": "src/test/resources/BulgNatlKeyKeyStore.eclipse.p12",
  "keyPairAlias": "bulgnatlfxtrading",
  "trustStoreName": "src/test/resources/BulgNatlTrustKeyStore.eclipse.p12"
}

As stated, the above .json file (e.g., TSFClient.json) must be identified in a .properties file. See Client Creation and Configuration page.



Parameters explained:

hostname

The dName of the server to connect to which may also be a load balancer. This is typically the ip address or DNS address of a load balancer (so that connections are distributed among a set of servers within the TSF). It can also have the value "localhost" if server is executing on the same workstation as TSFClient (which usually occurs only for testing) or the ip address of a specific server.

Default: None

port

The insecure port that the identified server is listening on for when this tSFClient is being used to connect to the server with an insecure (plain TCP/IP) connection. This value will be used if the value of "secureConnection" is false.

Default: 9090

SSLPort

The secure SSL port that the identified server is listening on for establishing a 2-way authenticated (note: not the normal 1-way authenticated) SSL connection. This value will be used if the value of "secureConnection" is true. Note: Because this is a 2-way authenticated SSL connection, the TSFClient must not only have access to a TrustStore (with server's X509Cert with public key signed by a valid root authority [noting that we can be that root authority if you request us to be]), but also access to a KeyKeyStore with the private key and associated X509Cert with public key that uniquely identifies that client.

Default: 9091

secureConnection

As explained above: If false, an insecure connection on port to the connected-to server (TSF Instance) identified by hostname (or to one of the TSF Servers sent to by the load balancer identified by hostname) will be attempted when the SuperMainExternalClientCmpnt is created (see above). If true, a 2-way authenticated secure connection on SSLPort to the connected-to server (TSF Instance) identified by hostname (or to one of the TSF Servers sent to by the load balancer identified by hostname) will be attempted when the SuperMainExternalClientCmpnt is created (see above).

Default: false

sessionId

Pass this sessionId as non-zero if you are trying to reconnect to an existing session you have established. See also actionAfterFinalReconnectFails, because, depending on that value, this sessionId may not be used in the event that the reconnects all fail.

Default: 0

numOfAttemptsToReconnect

If the SuperMainExternalClientComponent loses its connection to the TSF (which could happen if the server within the TSF Grid you are connected to goes down or if there is a network interruption, etc.), how many reconnect attempts will be attempted before the SuperMainExternalClientCmpnt your code has created throws an Exception to your code.

Default: 3

numMillisToWaitBetweenReconnectAttempts

This is the number of milliseconds to wait between reconnect attempts in the event of a lost connection.

Default: 2000 (e.g. 2 seconds)

acceptNewSessionOnReconnect

true if, when attempting to connect with a non-zero sessionId (meaning: when attempting to re-establish an existing session), the SuperMainExternalClientCmpnt will establish a new Session with the TSF server it reconnects with if the TSF cannot provide the prior session (e.g., if that session is expired or failed to save because the server that had been connected to had gone down prior to saving state). false if you only want to allow your SuperMainExternalClientCmpnt to reconnect if it can seamlessly re-establish the existing session -- otherwise, it will throw a LostConnectionException (or other similar Exception) to your code that is using this TSF SuperMainExternalClientComponent.

Default: false

actionAfterFinalReconnectFails

Possible values are AttemptNewConnWithNewSession, AttemptReConnWithCurrentSession, AttemptReConnWithSessionInParams and Terminate. It is important to spell the values exactly as shown here -- including capitalization.

Default: AttemptNewConnWithNewSession

requestTimeoutInMillis

When a synchronous message is sent to the server, how long to wait for a response before the SuperMainExternalClientCmpnt throws an Excecption to your client code.

Default: 0

numOfResponseProcessingThreads

This setting determines the number of processes that can be executed by the SuperMainExternalClientCmpnt's own threads simultaneously. You may use the SuperMainExternalClientCmpnt you have created to send multiple asynchronous messages (each of which may result in one or more responses to the callback methods within your own code that you provide to handle the responses). It is these SuperMainExternalClientCmpnt's Response Processing Threads that will execute your callbacks. If you set this to 1 and responses to different asynchronous commands come back, only one response can be handled at a time. Where this may matter is where your code executes a long process to handle the response received. Then, the 1 thread that can handle responses will be executing your code for a long time prior to being able to process other responses sent by your server code in the meantime. (Of course, you could always write your client code in a way where, your callback just puts the response on one of your queues and notify()s one of your threads to handle the response placed on the queue. But, then, you would have to write your own multi-threaded code on the client side. Using this capability, the threads of the TSF's SuperMainClientCmpnt can automatically handle the parallel processing of responses.) However, setting this to a value greater than 1 will mean that responses sent by your server code may not always be processed in the order these were sent.

Default: 9

connectionConfig

This parameter refers to the configurations when connecting an external client to the TSF grid.

Consists of the following sub-properties:

maxSendQueueDataSize -> here

maxReceiveQueueDataSize -> here

maxSendQueueSize -> here

maxReceiveQueueSize -> here

sendPingRequestEveryMillis -> here

receivePingRequestEveryMillis -> here


Common Parameters

Please see the Common Parameters for an explanation of client parameters above that are not explained here as these are common with server configuration parameters.

Created by Team Tessell