List of all configurable Register Service parameters: ​

This section provides an in-depth explanation of each of the parameters in the Register Service configuration file. As with the TSF Server, many of these parameters are optional and have built-in default values, however they are all configurable -- for a refresher on how to override certain parameters, click here.

gridName ​

Name of the grid that all TSF instances are part of. If the gridName is "TSF", each TSF server that gets added to this grid will be known as TSF:1, TSF:2, etc..

Default: "TSF"

acceptableTSFInstanceFailuresToStartGrid ​

When starting up the grid initially, some TSF instances may fail after starting or are unable to start at all. This property defines the number of TSF instances that are allowed to fail to still allow the grid to come up. If the number of TSF instances that have failed exceed this number, the grid will not start. As an example, let's suppose that the grid was configured to start with 9 instances - and while coming up, 2 instances fail. If the property 'acceptableTSFInstanceFailuresToStartGrid >= 2', the grid would be able to successfully start after marking these 2 instances as failed. Then, after the grid comes up, these instances can be brought back to operational.

Default: 0 (Grid cannot start if there are any instances that fail)

networkModel ​

The type of network model that the Register Service will use to start the grid. For more information on each of these network model types, click here.

Default: "RingNetworkModel"

networkModelParamsPathAndFileName ​

This parameter is the configuration file path of the network model configuration file json. This configuration file is specific to the network model type passed into the networkModel parameter -- for examples of what these configuration files would look like for each network model type, click here.

Default: ".../DefaultRingNetworkModel.json"

{
 "numOfInstances": 1,
 "numInstancesPerRing": 1
}

TSFInstanceToRegSvcHeartbeatInMillis ​

Has a corresponding TSF server parameter. This parameter is for the Register Service to detect that a TSF instance has failed while the grid is in the process of coming up. This variable becomes meaningless once the TSF grid comes up. Once the TSF is up, detecting if a server in the grid fails is done by other TSF instances that they are connected to. Before each TSF instance has instantiated their ISRs during the grid initialization process, there is no way to detect a server failing except through the Register Service.

Let's suppose this value is 5000 millisecnds:

This means that every 5 seconds, the Register Service will expect a heart beat from each of the TSF instances that have added themselves to the initializing TSF grid. If at any point the Register Service stops hearing heartbeats from any instance before the grid starts up, it will mark it as failed and notify the rest of the instances. In the TSF server configuration file (described below) there is a value with this same name which refers to how often each instance sends a heart beat. Again, once the grid starts up, this functionality is NOT how TSF instances are detected as failed.

Default: 5000 (e.g. 5 seconds)

networkServiceEndpoints ​

As described in the Network Service section above, the Network Service is how the communication between each TSF instance and the Register Service flows. This parameter describes the network service endpoints in which the Register Service should use to connect.

Ex. If 2 network services (named network-service-1, network-service-2) are configured with client port 2379 (more on this was explained in the above Network Service section), then the value of networkServiceEndpoints in this configuration file would be : ["http://network-service-1:2379","http://network-service-2:2379"]

Default: None - This parameter is required.

startGridAutomaticallyOnStartupAndAfterShutdown ​

This parameter refers to the behavior of how the TSF grid comes up initially or after a previous shutdown. There are 3 possible values for this parameter:

• NeverOpenGridAutomatically (Default)

This setting means that the grid will NOT start automatically on start up or after the grid shuts down and comes back up a secnd time. What will happen instead is all of the TSF instances in the grid will wait until the Register Service is instructed by our Management Console to allow TSF instances to add themselves, and only then will the grid start. Having this behavior allows the grid start up to be completely in the user's control if they want to make sure that all the components of the grid (Register Services, TSF servers, Network Service are all working and configured as expected before actually starting up the grid).

• OpenGridOnInitializationAndAfterShutdown

This setting is the opposite extreme of the one above -- the Register Service will start up allowing instances to automatically add themselves, and after a grid shutdown, if the TSF instances come back up, they will immediately get added again and the TSF grid will start up again without any special instruction.

• OpenGridOnlyOnInitialization

This setting is an in-between setting of the two above. It is similar to OpenGridOnInitializationAndAfterShutdown in that the Register Service will start accepting instances right away when the grid starts for the first time without any special instruction. However, it is like NeverOpenGridAutomatically in that after the grid is shutdown and instances are coming back up a second time, the Register Service will not accept instances until instructed to do so by the user through the Management Console.

ipAddressUtilityPort ​

We mentioned that the communication between TSF instances in the grid and the Register Service go through the distributed Network Service - there is a slight exception due to the following problem. In Java, there is no way to get your own machine's exact ip address. Knowing every machine's ip address in the grid is critical so that each server can connect to others in the grid. So, when each TSF instance comes up, it establishes a socket connection with the Register Service purely so that the instance can get its ip address. This socket connection is only for this purpose and is NOT used for TSF instances to communicate with the Register Service (again, that is done via putting / getting keys into / from the Network service). This parameter defines the port in which this socket connection is established on.

Default: 9777

The following two parameters, initialTimerInMillisForNetworkModelChangesToTakeEffect and timerExtensionInMillisForNetworkModelChangesCloseToTimerEnd, are referred to as timer-1 and timer-2 respectively for convenience. They are triggered due to changes in the grid's network model being either updated or regenerated. The only operations that this can happen are adding a new instance, requesting an instance to be shutdown, and returning a failed instance back to operational. These operations require all TSF instances in the grid either to update their network model or switch to a new one. If there are a lot of these events happening around the same time, we don't want to update and distribute the resulting network model to all TSF instance in the grid for each of these events. Instead, these timers are designed to group together these events in larger updates to the network model that encorporates many instances being added and/or shutdown.

initialTimerInMillisForNetworkModelChangesToTakeEffect ​

When an event comes to either add a new server, request a server to be shutdown, or return a failed server back to operational, timer-1 is initially started to wait a certain amount of configurable time. If no other events come during this time that would trigger another timer start, timer-2 is NOT used - when timer-1 finishes, all TSF instances in the grid are informed about the new changes / new network model and the grid adopts these changes (Ex. Services on new machines can be hit directly / indirectly, services shutdown will not have any traffic directed to or through it, servers that are returned to operational are now a part of the grid again).

Default: 60000

timerExtensionInMillisForNetworkModelChangesCloseToTimerEnd ​

Let's suppose that while timer-1 is active and still has time left, another event comes. There are 2 cases here:

For this example, we will use the default values for each timer, so timer-1 = 60 seconds, timer-2 = 20 seconds. In each of these cases, we start with a new TSF instance being added while the TSF is up, initially starting timer-1.

Case 1: After 15 seconds go by in timer-1 (45 seconds left), another TSF instance is added. Since 15 + 20 (timer-2) is less than the original timer set to timer-1 (60), timer-1 is NOT extended, and both new TSF instances will be added after the remaining 45 seconds run out.

Case 2: After 45 seconds go by in timer-1 (15 seconds left), another TSF instance is added. Since 45 + 20 (timer-2) is greater than the original timer set to 60 (timer-1), timer-1 is extended by timer-2 seconds - In this case, the timer that was initially set to 60 is not 45 + 20 (timer-2). When the rest of this new timer goes off, both instances will be processed. If more instances are added, this cycle will keep happening as events keep coming in within timer-2 seconds of the current timer.

Default: 20000

<-Go back