Session-bound request processing

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

For them, G1 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 G1: either through a cookie sent along with the request that will contain the identity of G1 or through a part of the URL of the request that will link to G1. 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 (G1 in our example) , the piece of information to identify G1 will be added to the request and/or to its response in order to route following requests to G1.

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


Diagram of processing a cookie-based starting-session request, described elsewhere in this topic.

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 G1.
  3. The request is forwarded to G1.
  4. G1 creates the session S1.
  5. The response is returned to the load balancer server.
  6. A session cookie that holds the identity of G1 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


Diagram of processing a cookie-based session-bound request

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 C1 to the load balancer server.
  2. The load balancer server, thanks to C1, recognizes that the request must be routed to G1.
  3. The request is forwarded to G1.
  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 G1, whether it is a session-bound or a sessionless request.

Path-based starting-session request processing


Diagram of processing a path-based starting-session request

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, G1 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 G1.
  3. Once G1 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 G1.
  5. G1 creates the session S1.
  6. The response is returned to the load balancer server.
  7. The response is returned to the client.

Path-based session-bound request processing


Diagram of processing a path-based session-bound request

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 G1.
  3. The request is forwarded to G1.
  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 G1, respectively G2, whether it is a session-bound or a sessionless request.