When the realm service and proxy are running on a subnet that is different from the one on which the client application is running, you must configure the external host and port settings in the configuration file.
You can use a command-line parameter with the tibdgproxy process to specify the external host and port. The -e option followed by the IP address and the port number helps the client reach the proxy on a different subnet. If you specify the command-line option, it overrides the values set for proxy_client_listen_external_host and proxy_
client_listen_external_port in the configuration file. For more details on setting proxy_
client_listen_external_host and proxy_client_listen_external_port, see Configuration Options when the Proxy and Client are on Different Subnets.
Before you begin
l The following components must be running and reachable:
o The realm service o The state keeper
o At least one node of each copyset
l The data grid definition in the realm service must be complete and valid.
Procedure
1. Start the proxy process.
tibdgproxy -n name -r realm_service_URL -e External IP Address:Port
The name of the Proxy process is required. Supply one of the proxy names you assigned in Defining a Data Grid. The URL of the realm service is required. If the client is trying to reach a proxy on a different subnet, provide the -e option followed by the IP address and the port number. Here is an example to start the proxy and set
66 | Starting a Proxy
the external host and port:
tibdgproxy -r http://localhost:8080 -e "192.168.1.136:7999" -n p3
Warning: The command overrides any configuration value that is already defined for this proxy.
If the proxy is on one of several known external IP addresses, use a semicolon separated list of IP addresses in the command-line parameter. Also, see the docker-compose file in the TIBCO_HOME/as/<version>/samples/docker folder for an
example on using different proxy configuration options that allow client applications on the host to communicate with a proxy running in a docker container.
2. Verify whether the proxy process is ready by checking the status by using the administration tool.
3. Repeat the previous steps for all the proxy names assigned in the data grid definition.
What to do next
The data grid is ready to support data operations. You can start application program processes.
67 | Methods of Selecting a Proxy for a Client
Methods of Selecting a Proxy for a Client
ActiveSpaces client communication with the data grid always goes through an
ActiveSpaces proxy (tibdgproxy). When multiple proxies exist in a data grid, you might want to control which proxy your clients connect to. There are three methods of selecting a proxy for the client - random binding strategy, named binding strategy, and balanced binding strategy. By default, the random binding strategy is in effect. If you want more control over proxy selection, use the named binding strategy. To balance the available client connections across the number of proxies, use the balanced binding strategy.
Random Binding Strategy
By default, the random binding strategy is used to select a proxy for a client connection.
Here a proxy is chosen at random from the proxies that respond when the client first connects to the data grid. By default, the client connection waits for the CONNECT_WAIT_
TIME to expire before selecting a proxy. Use the early cutoff property to notify the client connection to only wait until a certain number of proxy responses are received. Using this property reduces the amount of time taken for the client to establish a connection with the data grid.
In this method, specify the following properties:
TIBDG_CONNECTION_PROPERTY_LONG_BINDSTRATEGY = TIBDG_CONNECTION_
After receiving the specified number of proxy responses, the client stops waiting for more proxy responses and chooses randomly between the responses already received.
If TIBDG_CONNECTION_PROPERTY_LONG_CONNECT_NUMRESPONSES value is set higher than the number of active proxies, it has no noticeable effect. The value must be set high enough to get a good distribution of clients among proxies. A general guideline would be to set the value to be approximately 50%-80% of the number of proxies in the system.
Without using the early cutoff, the proxy response time does not directly affect the
68 | Methods of Selecting a Proxy for a Client
reach the client in time. If you need a response from all proxies, you must wait for the slowest proxy to respond before a proxy is selected for the client connection.
The following are the possibilities of an early cutoff considering CONNECT_NUMRESPONSES=8: l By default, the CONNECT_WAIT_TIME is 100ms and a client waits for that interval before
collecting responses from proxies that are running. Then, the client randomly chooses one of those proxies to establish a connection.
l If you have eight proxies and you set CONNECT_NUMRESPONSES=8, there is a probability of having an early cutoff. If all 8 proxies respond within 5ms, connection can be established within 5ms. If one proxy is down or is busy and does not respond until 200ms, the client waits for 100ms and then selects a proxy for the connection. This is why specifying the CONNECT_NUMRESPONSES=8 is a good practice, especially if you know the total number of proxies that are configured.
l You can specify the CONNECT_NUMRESPONSES=8 to some percentage of the total
proxies. As per the example, if you consider 50% of the total proxies, there would be 4 proxies. The client stops waiting after 4 proxy responses have been received.
Maybe the first 4 responses come back in 3ms and then the other ones range from 5ms to 200ms. The client stops waiting at 3ms after the first 4 responses, which is better than waiting for 100ms.
Named Binding Strategy
In the named binding strategy, the client can choose from a predefined list of proxies.
Consider a scenario where you have two applications - one that executes GET, PUT, and DELETE operations in response to business logic and the other that performs
administrative operations such as creating or deleting tables. You want them to be bound to separate proxies so the important business logic is not delayed by the less predictable, more expensive administrative operations. In such a scenario, use the named binding strategy to bind the business application on proxy1 or proxy2 and the administrative application on proxy3 or proxy4. In most cases, a primary and failover proxy must be enough.
To enable the named binding strategy, set the following properties:
TIBDG_CONNECTION_PROPERTY_LONG_BINDSTRATEGY = TIBDG_CONNECTION_
BINDSTRATEGY_NAMED
TIBDG_CONNECTION_PROPERTY_STRING_CONNECT_PROXYNAMES =
"proxy1|proxy2|proxy3"
69 | Methods of Selecting a Proxy for a Client
Here, proxy1|proxy2|proxy3 is a list of proxies. The delimiter used to separate the list of proxies is a | (pipe) symbol. The highest priority proxy is specified first in this list followed by the others. The last proxy mentioned has the lowest priority.
If you are using the C API, pass the Properties object as an argument to tibdgGrid_
Connect(). If you are using the Java API, pass the Properties object as an argument to
DataGrid.Connect().
When the named binding strategy is configured, the client binds to the proxy with the highest priority. Usually, the highest priority proxy responds within the duration of the waiting time specified for a connection. If the highest priority proxy responds, the client stops waiting so the operations can begin.
If the proxy does not respond in time, the client waits out the CONNECT_WAIT_TIME and binds with the next highest priority proxy. The named binding strategy can be used to ensure that loads between proxies and clients can be balanced more carefully if the default random matching is not preferred.
Balanced Binding Strategy
Based on the number of current connections, you can use the balanced binding strategy to balance the client connections across the available proxies. When all proxies have the same number of connections, the balanced binding strategy works like the random binding strategy. For example, when the grid starts, all proxies have zero client connections. As a result, the balanced binding strategy randomly assigns clients to
proxies. By default, the client connection waits until the wait time for a connection expires and then selects a proxy. Optionally, you can use the early cutoff property to notify the client connection to only wait until a certain number of proxy responses are received.
Using this property reduces the amount of time taken for the client to establish a connection with the data grid.
To enable the balanced binding strategy, set the set the BINDSTRATEGY property and optionally set the NUMRESPONSES property.
TIBDG_CONNECTION_PROPERTY_LONG_BINDSTRATEGY = TIBDG_CONNECTION_
BINDSTRATEGY_BALANCED
TIBDG_CONNECTION_PROPERTY_LONG_CONNECT_NUMRESPONSES = n
Where n is the number of proxy responses that you want the client to wait for before selecting a proxy. The property is set on the Connnection object's properties.
70 | Methods of Selecting a Proxy for a Client
The default CONNECT_WAIT_TIME is 100ms, which means that the client waits for this time before selecting a proxy. If you want the client to wait longer, then set the following property:
TIBDG_CONNECTION_PROPERTY_DOUBLE_CONNECT_WAIT_TIME = m
Where m is the number of seconds that you want the client to wait.
When the balanced binding strategy is enabled, the client performs the following tasks:
l Collects the responses from the proxies that responded in time l Chooses to bind to the proxy with the fewest clients
l Notifies the remaining proxies that they have been rejected.
If several clients connect to the grid at the same time, they might all choose the same proxy leading to an unbalanced distribution across the proxies. For more information about how to rebalance the clients, see the tibdg proxy shed command.
71 | Adding Copysets