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 the proxy to which your clients connect. The following methods are available to select a proxy for a client:
-
Random binding strategy
-
Named binding strategy
-
Balanced binding strategy
-
Random pattern binding strategy
-
Balanced pattern binding strategy
By default, the random binding strategy is used. 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. Use the pattern binding strategies to filter proxies by using a regular expression before binding.
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 wait only 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_BINDSTRATEGY_RANDOM TIBDG_CONNECTION_PROPERTY_LONG_CONNECT_NUMRESPONSES = nHere,
n
is the number of proxy responses.
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().
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 theTIBDG_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.
early cutoff
property, the proxy response time does not directly affect the binding process, unless the
CONNECT_WAIT_TIME
property is configured so low that no responses 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
:
- By default, the
CONNECT_WAIT_TIME
property value is 100 ms 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. - If you have eight proxies and you set
CONNECT_NUMRESPONSES=8
, there is a probability of having an early cutoff. If all eight proxies respond within 5 ms, the connection can be established within 5 ms. If one proxy is down or is busy and does not respond until 200 ms, the client waits for 100ms, and then selects a proxy for the connection. This is why specifyingCONNECT_NUMRESPONSES=8
is a good practice, especially if you know the total number of proxies that are configured. - 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 four proxies. The client stops waiting after four proxy responses have been received. Maybe the first four responses come back in 3 3 ms and then the other ones range from 5 ms to 200 ms. The client stops waiting at 3 ms after the first four responses, which is better than waiting for 100 ms.
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 runs 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 fail-over 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"
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
value 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 wait only 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 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.
The default CONNECT_WAIT_TIME
is 100 ms, 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:
Collects the responses from the proxies that responded in time
Chooses to bind to the proxy with the fewest clients
Notifies the remaining proxies that they have been rejected.
Note: 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.
Pattern Binding Strategy
There are two pattern binding strategies - random and balanced that are used to bind clients to proxies by using PCRE2 regular expression to match the proxy names. You can use these strategies to bind clients to proxies based on a pattern. For example, you can bind clients to proxies based on the location of the client or the type of operation that the client performs. Alternatively, you can use a pattern to specify a list of named proxies as a regular expression just like the named binding strategy. However, unlike the named binding strategy, each matching proxy is given equal weight instead of a priority-ordered list.
The difference between the pattern-based and non-pattern based binding strategies is how a proxy is chosen from the list of proxies that match the pattern. The pattern random binding strategy selects a proxy at random and selects the proxy with the fewest clients just like the balanced binding strategy. The pattern binding strategies also honor the CONNECT_WAIT_TIME
and CONNECT_NUMRESPONSES
properties. For example, consider a grid where proxies are spread among different availability zones, and the zone name is part of the proxy name. For example, zone1-p1, zone1-p2, zone2-p1, and zone2-p2. To enable a client in zone1 to bind to a random proxy in zone1 only, use the pattern random binding strategy. Set the BINDSTRATEGY
property to TIBDG_CONNECTION_BINDSTRATEGY_PATTERN_RANDOM
and the PROXYPATTERN
property to '^zone1-.*'
. The pattern '^zone1-.*'
matches all the proxies in zone1 and the client binds to a random proxy in zone1.
To enable a pattern binding strategy, set the following properties:
TIBDG_CONNECTION_PROPERTY_LONG_BINDSTRATEGY = TIBDG_CONNECTION_BINDSTRATEGY_PATTERN_RANDOM # or TIBDG_CONNECTION_BINDSTRATEGY_PATTERN_BALANCED
TIBDG_CONNECTION_PROPERTY_STRING_CONNECT_PROXYPATTERN = "pattern" # mandatory if the pattern random or pattern balanced binding strategy is used
TIBDG_CONNECTION_PROPERTY_LONG_CONNECT_NUMRESPONSES = n # optional
TIBDG_CONNECTION_PROPERTY_DOUBLE_CONNECT_WAIT_TIME = m # optional