Open topic with navigation

TIBCO ActiveSpaces® 4.8.0

# 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_BINDSTRATEGY_RANDOM
    TIBDG_CONNECTION_PROPERTY_LONG_CONNECT_NUMRESPONSES = n

Here, `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 `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 binding process, unless the `CONNECT_WAIT_TIME` 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` 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.
- 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.
- 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"

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.

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:

- 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.

  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.

Copyright © 2009-2022. Cloud Software Group, Inc. All Rights Reserved.