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
Figure 1. Cookie-based
starting-session request processing
Figure 1shows
the processing of a cookie-based starting-session request. It takes
the following steps:
- GDC (or a user agent on the behalf of GWC) sends a request to
the load balancer server.
- The load balancer server is configured to dispatch the requests
over two GAS instances. In this example, it happens to choose the
instance G1.
- The request is forwarded to G1.
- G1 creates the session S1.
- The response is returned to the load balancer server.
- A session cookie that holds the identity of G1 is added
to the response so that following requests will also contain this
cookie.
- 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:
- GDC (or a user agent in behalf of GWC) sends a request that contains
the cookie C1 to the load balancer server.
- The load balancer server, thanks to C1, recognizes
that the request must be routed to G1.
- The request is forwarded to G1.
- The response is returned to the load balancer server.
- 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
Figure 3. Path-based starting-session
request processing
Figure 3shows
the processing of a path-based starting-session request. It takes
the following steps:
- GDC (or a user agent in behalf of GWC) sends a request to the
load balancer server.
- 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.
- 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.
- The request is forwarded to G1.
- G1 creates the session S1.
- The response is returned to the load balancer server.
- 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:
- GDC (or a user agent in behalf of GWC) sends a request who's URL
begins with /GAS1 to the load balancer server.
- The load balancer server, thanks to the /GAS1 prefix, recognizes
that the request must be routed to G1.
- The request is forwarded to G1.
- The response is returned to the load balancer server.
- 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.