Article Original Creation Date: 2010-05-20
Problem
What is the behavior associated with ACS parameter SERVER_WAITING_QUEUE_TIMEOUT?
Environment
ServiceGateway (SG) 4.x
Solution
The SERVER_WAITING_QUEUE_TIMEOUT works as follows. When the SG AS makes a call to the ACS API to invoke the SetParameterValues RPC, the ACS API first checks to see if the device is already in an active session with that device. If not, then the ACS API issues the HTTP GET to tickle the device and the communication proceeds as expected.
If the device is already in an active session, then the ACS API will load the SetParameterValues RPC into the server waiting queue (SWQ), expecting that the RPC will be delivered as part of the current active session with the device. If that RPC is still sitting in SWQ after SERVER_WAITING_QUEUE_TIMEOUT expires, we interpret this to mean that the session with the device ended without the RPC being sent. At this point the ACS API will issue an HTTP GET to start a new session with the device in order to deliver the SetParameterValues RPC.
This is necessary due to the separation between the ACS API and the ACS-server. While the ACS API tickles the devices, it is the ACS-server that has the session with the devices. Since these are separate processes and may be on separate servers, the database is used to indicate whether a device is in an active session or not. Since there are multiple processes involved, there is the possibility of a race condition when the ACS API checks whether the device is already in a session, and when the ACS-server closes that session. This timeout was added to handle this potential race condition, so that if the session is in fact closed before the RPC is delivered, the ACS API will issue the HTTP GET to start a new session.
If the device is already in an active session, then the ACS API will load the SetParameterValues RPC into the server waiting queue (SWQ), expecting that the RPC will be delivered as part of the current active session with the device. If that RPC is still sitting in SWQ after SERVER_WAITING_QUEUE_TIMEOUT expires, we interpret this to mean that the session with the device ended without the RPC being sent. At this point the ACS API will issue an HTTP GET to start a new session with the device in order to deliver the SetParameterValues RPC.
This is necessary due to the separation between the ACS API and the ACS-server. While the ACS API tickles the devices, it is the ACS-server that has the session with the devices. Since these are separate processes and may be on separate servers, the database is used to indicate whether a device is in an active session or not. Since there are multiple processes involved, there is the possibility of a race condition when the ACS API checks whether the device is already in a session, and when the ACS-server closes that session. This timeout was added to handle this potential race condition, so that if the session is in fact closed before the RPC is delivered, the ACS API will issue the HTTP GET to start a new session.
As soon as we deliver an RPC to a device, we set SPRT_NC_SERVER_WAITING_QUEUE.NC_SWQ_STATUS to be 1, meaning that we have sent the RPC to the device, but have not received a response from the device (the other values for this column are 0, meaning that the RPC has not yet been sent to the device, and 2, which means that the RPC has been sent to the device AND the device has responded). So when SG looks for RPCs that have been queued in but not yet sent, it only looks for those with NC_SWQ_STATUS=0.
So the device will not get a tickle if it takes longer than SERVER_WAITING_QUEUE_TIMEOUT for an actual RPC response if the RPC has already been sent to the device.