Configure passive HTTP session affinity in the on demand router
When the on demand router (ODR) processes a request, it obtains the session affinity descriptor policy of the cluster to which the server belongs. If we changed the default settings for any middleware servers, we might need to update the middleware descriptor properties so that the ODR can obtain the descriptor policy. In most cases, the on demand router (ODR) does not require configuration to support HTTP session affinity. However, some special cases exist where configure the ODR to learn about backup servers that the back end servers might be setting on the session affinity cookie.
The servers in the configuration must be in a generic server cluster or a dynamic cluster. We can use passive HTTP session affinity with a static cluster.
In environments where the ODR forwards requests to generic server cluster members and to non-federated WebSphere Application Server servers, a set of properties must be set for the ODR to correctly uphold session affinity. Passive HTTP session affinity means that the ODR passes the session cookie set by the backend server through to the client, as opposed to the ODR setting the WSJSESSIONID cookie. Passive HTTP session affinity is used in the following situations:
- When the ODR routes to servers that are not running WebSphere Application Server middleware products.
- When the ODR routes to WebSphere Application Server application servers that are in different core groups that are not connected by the core group bridge.
- When the application uses Java EE HTTP session affinity that is not standard. For example, the application's session ID cookie name is something other than JSESSIONID
- If any of the default values for the server have changed, modify the session affinity descriptor.
In the console, click System administration > Middleware descriptors > middleware_server > default.
- Define the session affinity descriptor properties. Modify the values for any of the following fields that apply:
- Learn clone IDs
- Cookie names
- URL rewrite
- Clone ID separator
- Alternate clone ID separator
- Affinity mode
Set the value of the Learn clone IDs field to true so that the ODR parses the clone IDs from the response cookie sent back to the client. Because the ODR recognizes the server that sends the response back at this point, the parsed clone ID is associated with the server. Therefore, future requests are matched against the known set of clone IDs in order to uphold session affinity in other middleware server environments. Set the Learn clone IDs field to true when the ODR does not have an on demand configuration of the server. Note that the ODR can only parse the response cookie if the session ID is in a JSESSIONID format that the ODR understands.
The Cookie names field indicates which response header contains session ID information, and should be parsed to determine the clone ID. The Clone ID separator field indicates on which part of the session cookie the Clone ID field begins. The Cookie names and Clone ID separator fields are also used by the ODR to parse the clone IDs from the request cookie to enforce session affinity.
In cases where there is no on demand configuration information for servers, such as servers that are members of generic server clusters, set the Learn clone IDs field to true so that the ODR parses the session ID for the clone ID. If the session ID in the response is not in the JSESSIONID format, set the affinity mode to Active[-conditional] affinity. In this case, the ODR internally assigns each backend application server a clone ID, which is set in the WSJSESSIONID header. As a result, the ODR maintains session affinity when operating with backend environments that cannot generate session IDs in the JSESSIONID format. Active affinity means that the ODR always sets a WSJSESSIONID cookie with the clone ID of the backend server that is sending the response. Active-conditional affinity means that the ODR sets only the WSJSESSIONID cookie if it recognizes the Set-Cookie header in the response.
In WebSphere Application Server environments where the clone IDs are available to the ODR by way of the on demand configuration, the clone ID information is never learned by setting the Learn clone IDs field to true. The clone IDs are available to the ODR by way of the on demand configuration, if the ODR is in the same core group as the application servers, if the ODR is in a different core group but the core groups are bridged, or if the bulletin board service overlay network (BBSON) is enabled. BBSON is enabled by default.
When the ODR processes a request, it obtains the session affinity descriptor policy configured for the cluster to which the server belongs. The method in which the server clone identification is obtained depends on the property values of the policy attributes.
Overview of request flow prioritization BBSON bulletin board
Create ODRs Route requests to external nodes with generic server clusters