What happens to a call if policy server A goes down and B is running (Legacy_Onyx KB Id: 193639)
search cancel

What happens to a call if policy server A goes down and B is running (Legacy_Onyx KB Id: 193639)


Article ID: 54464


Updated On:


CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign-On



Suppose that I make an authorize call with valid Session specs, Resource and Action.

Now, the Moment when the request reaches the policy server the
server goes down or the "smpolicysrv" process gets defunct.
Now as per understanding the request gets timed out ie the

Now suppose I have another server 'B' configured for failover.
What will happen to my request in this case ? Ie when my request reached policy server 'A' and its process gets defunct or dies; then will the Request be rerouted to policy server 'B' ? ie. will the I get SUCCESS inspite of the fact the policy server 'A' went down.

Note* I am very specifically talking about the case where request has already reached the server and the server process "smpolicysrv" dies or gets defunct.

Also if i talk of another scenario wherein my Policy servers 'A' and 'B' both go down; then what will happen to the Session specs . I mean will the User be authorized with the same session specs after the policy server is restarted and another authorize call is made with the same session spec.


Important points in this scenario is that the Policy Server process is alive to receive the request and the process goes defunct without the open connections being closed or reset. If the Policy Server process died before the request reached the Policy Server or the Policy Server side of the connections closed, the Agent would immediately see an error condition.

When the Agent sends the request to Policy Server A and at the TCP level the packet is acknowledged so the Agent system does not know the Policy Server process goes down, the Agent will wait the defined Agent request time out. The Agent will then reset the connection on which no reply was received and clean up any connection in its connection pool that has been idle longer than the connection that failed. The Agent will then establish new connections and repeat the request to Policy Server B.

The retry is handled within the communication code. The Agent API return code is not returned until a successful message is received from the Policy Server or each configured Policy Server is tried at least once. Simplest case, where the Agent has established connections to A and B and can re-establish connections for the retry will result in a try to A and a retry to B. In other scenarios, can result in more than one retry per Policy Server. For example if the Agent loses connectivity to the Policy Server and has trouble reestablishing connections to some Policy Servers, the number of retries may be greater than one per Policy Server. The maximum retry attempts in the worst case scenario, would be twice per Policy Server.

The Session Spec will still be validated by the Policy Server after the Policy Servers become accessible as long as the session timeouts defined at authentication time have not expired in the interim.


Component: SMSDK