Methods to Select 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 two methods of selecting a proxy for the client - random binding strategy and named binding strategy. By default, the random binding strategy is in effect. If you want more control over proxy selection, use the named binding strategy.

Random Binding Strategy

By default, 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 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 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 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.