List of all configurable parameters that are common to BOTH server and client: ​

The following parameters are common to configuring the TSF Server AND the SuperMainExternalClientCmpnt that your client code instantiates to connect to the TSF to use your Services - default values can be overridden just like the other parameters in the TSF Server configuration file

autoVerifySignedMsgPkg ​

If true on the server, then, whenever a signed Msg is recieved, it will NOT be passed to the target Service without our server TSF components auto-verifying the msg first. Furthermore, if verified, the msg/request sent along with its signature and the DName of the key that signed it is stored in the ServerSignature table allowing for later non-repudiation -- proving (from a legal standpoint [at any time, after the action]) that the sender sent it from a device where they had the private key AND logged in with a user name and password that was not only valid but matched that private key.

Default: false (but should probably be made true on the server side if using the TSF's secure 2-way connection)

sendSignedMsgPkg ​

Even on the client side, this should usually be false as it is always possible for a client to send a signed message (if client has connected with the TSF's secure 2-way connection) for any given request and only certain requests are likely to require signing (and storing and non-repudiation capabilities) when these are sent.

Default: false (and should probably be false server side even if your client is connected using our 2-way secure SSL connection)

signatureAlgorithm ​

The signature algorithm that is used for both signing sent messages and verifying received messages.

Default: "SHA256withRSA"

keyStoreName ​

Path and name of the KeyKeyStore with end user's public key in an X509 Certificate and their private key. (The password for this KeyKeyStore is in the token file identified in the .properties file.) This only needs to be provided if the SuperMainExternalClientCmpnt is being created for use on a secure (i.e., SSLPort). (Of course, on the server side, the DName and SerialNumber of the X509 Certificate with the end user's public key needs to be part of the ACL entry for that end user [rather than just the userName and password that would be needed if we were using said SuperMainExternalClientCmpnt for an insecure connection to port].)

Default: None

keyPairAlias ​

This is the alias of the public-private KeyPair within the KeyKeyStore file with the key that will be used when the user tries to establish a 2-way authenticated SSL connection on the secure (i.e., SSLport). This only needs to be provided if the SuperMainExternalClientCmpnt is being created for use on a secure (i.e., SSLPort).

Default: None

trustStoreName ​

Path and name of the TrustKeyStore with your company's server's X509 Certificate with your company's public key. The X509 Certificate must be part of the KeyPair that you use for the execution of the TSF within your Company's compute farm -- i.e., on the server side, it must be the X509Certificate that is part of the KeyPair of public-private key accessed within server's KeyKeyStore. (The password for this TrustKeyStore is in the token file identified in the .properties file.) This only needs to be provided if the SuperMainExternalClientCmpnt is being created for use on a secure (i.e., SSLPort).

Default: None

numOfRetryAttemptsOnQueueFailForReceptionCmpnt and queueFullRetryIntervalInMillisForReceptionCmpnt ​

When the queue is past its capacity in either number of entries or total size of all entries (as determined by "" and "", respectively), the ReceptionCmpnt's thread will stop accepting new data from the connection and wait (if the default values are used) 2 seconds up to 3 times waiting for this condition to clear. I.e., the queue full condition as set in maxReceiveQueueSize and maxReceiveQueueDataSize will be checked to see if either is still true after 2, 4 and 6 seconds. If, using both these checks, the queue is not full after 2 seconds, processing will resume. If either one of these conditions (number of entries OR size) still indicates that the queue is full after 2 seconds, the TSF will wait for another 2 seconds and check again. If both checks pass after 2, 4 or 6 seconds, processing of the information received on the socket will resume and no QueueFullException will be thrown.

Default for numOfRetryAttemptsOnQueueFailForReceptionCmpnt: 3

Default for queueFullRetryIntervalInMillisForReceptionCmpnt: 2000 (i.e., 2 seconds)

numOfRetryAttemptsOnQueueFailForTransmissionCmpnt and queueFullRetryIntervalForTransmissionCmpnt ​

If defaults are left in place, a TransmissionCmpnt will wait 2 seconds up to 3 times for this queue full situation to clear before "giving up" and throwing a QueueFullExeption to either your server Service code (if these parameters are for your TSF Grid Config's TSF Instances) or to your client code (if it is the SuperMainClientCmpnt that is trying to send too much to the server). See maxSendQueueSize and maxSendQueueDataSize.

Default for numOfRetryAttemptsOnQueueFailForTransmissionCmpnt: 3

Default for queueFullRetryIntervalForTransmissionCmpnt: 2000 (i.e., 2 seconds)