Session-bound request processing

With session-bound requests, more work has to be done in order to route session-bound requests to the GAS (G₁) instance that handles the session.

For them, G₁ must be retrieved from the data of the request. The load balancing tool does not record the currently active GAS sessions. Actually, it even doesn't know anything about GAS sessions at all. It offers other means to retrieve G₁: either through a cookie sent along with the request that will contain the identity of G₁ or through a part of the URL of the request that will link to G₁. This piece of information is added to the request that will create the session. This starting-session request is sessionless, and can therefore be processed by any of the available GAS instances. However, once that instance has been chosen (G₁ in our example) , the piece of information to identify G₁ will be added to the request and/or to its response in order to route following requests to G₁.

The following paragraphs discuss the two kinds of configuration for the load balancing of session-bound requests: cookie-based and path-based. For each method, first the processing of the starting-session request is shown, and then the processing of the session-bound requests is shown.

Cookie-based starting-session request processing

Figure 1. Cookie-based starting-session request processing

Figure 1shows the processing of a cookie-based starting-session request. It takes the following steps:

1. GDC (or a user agent on the behalf of GWC) sends a request to the load balancer server.
2. The load balancer server is configured to dispatch the requests over two GAS instances. In this example, it happens to choose the instance G₁.
3. The request is forwarded to G₁.
4. G₁ creates the session S₁.
5. The response is returned to the load balancer server.
6. A session cookie that holds the identity of G₁ is added to the response so that following requests will also contain this cookie.
7. The response is returned to the client.

Cookie-based session-bound request processing

Figure 2. Cookie-based session-bound request processing

Figure 2shows the processing of a cookie-based session-bound request. It takes the following steps:

1. GDC (or a user agent in behalf of GWC) sends a request that contains the cookie C₁ to the load balancer server.
2. The load balancer server, thanks to C₁, recognizes that the request must be routed to G₁.
3. The request is forwarded to G₁.
4. The response is returned to the load balancer server.
5. The response is returned to the client.

Note: Every request received by the load balancer server that contain C1 will be routed to G₁, whether it is a session-bound or a sessionless request.

Path-based starting-session request processing

Figure 3. Path-based starting-session request processing

Figure 3shows the processing of a path-based starting-session request. It takes the following steps:

1. GDC (or a user agent in behalf of GWC) sends a request to the load balancer server.
2. The load balancer server is configured to dispatch the requests over two GAS instances. Each of these instances must be configured so that URLs that it handles begin with a part that is unique between all GAS instances, whether the GAS instances are installed on the same machine or different ones. In this example, G₁ handles requests whose URLs begin with /GAS1, and G2 handles requests whose URLs begin with /GAS2. In this example, it happens to choose the instance G₁.
3. Once G₁ has been chosen, the URL of the request is rewritten so that it begins with /GAS1. This prefix will be recognized by the GAS as the connector URI part of the URL. The GAS adds the connector URI to every URL that is part of the request responses.
4. The request is forwarded to G₁.
5. G₁ creates the session S₁.
6. The response is returned to the load balancer server.
7. The response is returned to the client.

Path-based session-bound request processing

Figure 4. Path-based session-bound request processing

Figure 4shows the processing of a path-based session-bound request. It takes the following steps:

1. GDC (or a user agent in behalf of GWC) sends a request who's URL begins with /GAS1 to the load balancer server.
2. The load balancer server, thanks to the /GAS1 prefix, recognizes that the request must be routed to G₁.
3. The request is forwarded to G₁.
4. The response is returned to the load balancer server.
5. The response is returned to the client.

Note: Every request received by the load balancer server that begins with /GAS1, respectively /GAS2, will be routed to G₁, respectively G2, whether it is a session-bound or a sessionless request.