API Gateway Policy Manager access fails with "Inactivity timeout reached" message immediately upon login

Document ID : KB000044775
Last Modified Date : 10/08/2018
Show Technical Document Details
Issue:

You will observe "Gateway Inactivity Session Timeout" error pop up when connecting to API Gateway cluster. The message is almost immediate other than the normal message indicating that the session for the admin login has been idle for too long. 
 

Environment:
API Policy Manager connecting to a Gateway cluster of any version.

The caveat here is that the host information entered into the Policy Manager login screen is to a Load Balancer that is distributing the connection attempt to any of the Gateways in the cluster. 
 
Cause:
This message in the Gateway ssg log will imply that reuse of a logon cookie for a session is not possible as it has expired and the logon could be from policy manager, web based policy manager or from script.  

Another possibility is if someone else is working in parallel with you using a web based policy manager and trying to click on options even after the session is expired, possible that the error is not from your session.

 com.l7tech.server.admin.AdminSessionManager: Admin session/cookie not found: <not shown>

In this instance since a Load Balancer is 'front-ending' the Policy Manager, the traffic is getting round-robin between the underlying two or more cluster gateway hosts, and in no time when the traffic hits the second host it comes back with exception saying no session cookies were found.
 
Resolution:
CA Support recommends to establish a sticky session policy on your Load Balancer to mitigate this problem. There are a few ways to accomplish this. CA Support will not go into great detail on the methods to achieve this as this is out of Support scope.
  1. Establish a Destination Address Persistence session policy. This is the simplest and most recommended method but not the most robust. 
  2. Establish an IP source affinity policy. Otherwise known as "balance source". This does not however guarantee the same concrete 'sticky-ness' that a Persistence policy would bring.
Additional Information:
This diagram shows the potential benefit of using a Session Persistence scheme over a load-balancing algorithm:
 
      client request
            |
            V
        HA Front-end
            |
            V
     Back-end choice
            |
            V
        HA Back-end
            |
            V
Does the request contain
persistence information ---------
            |                   |
            | NO                |
            V                   |
    Server choice by            |  YES
load-balancing algorithm        |
            |                   |
            V                   |
   Forwarding request <----------
      to the server

Which means that when doing session persistence in a load balancer, the following happens:
 
  • the first user’s request comes in without session persistence information
  • the request bypasses the session persistence server choice since it has no session persistence information
  • the request passes through the load-balancing algorithm, where a server is chosen and affected to the client
  • the server answers back, setting its own session information
  • depending on its configuration, the load-balancer can either use this session information or setup its own before sending the response back to the client
  • the client sends a second request, now with session information he learned during the first request
  • the load-balancer chooses the server based on the client side information
  • the request DOES NOT PASS THROUGH the load-balancing algorithm
  • the server answers the request


 Additionally, you may need to close and relaunch the policy manager for these changes to take affect.

 Links: