VXML Server: Session Loss During a Call Error
Rapid Multiple Sequential Applications Warning
|Problem Summary||This warning message appears when an HTTP request that is not initiated by the root document is made by the browser for a session that VXML Server has started the process of ending, and a built-in error-correcting mechanism within the VXML Server has attempted to resolve the issue by ignoring the cookie hence issuing a warning rather than an error. While the scenario is similar to previous errors, this is a warning, not an error since the call itself was handled without the caller encountering any error messages. The warning message is logged to inform the administrator of a situation that could indicate high call volume, which could cause other more severe issues.|
|Error Message||SERVER ERROR: Warning: An HTTP request was made to a session that has been slated for invalidation. It is treated as if not associated with a session.|
|Possible Cause||The likeliest situation that would cause this warning message to appear involves a setup where a VXML Server application is configured to return to Unified ICME, that after some processing promptly visits a second application within the same call. Due to the fact that these two applications are visited in the same call, the cookie created in the first application and stored by the browser is referenced in the first HTTP submit to the second application. This is not normally an issue because the first application’s session ends before the next application’s first submit is made, especially if the ICM script performed time-consuming tasks before visiting the second VXML Server application. However under high volume, the process for ending a session may not take a trivial amount of time. Additionally, if the ICM script completes in a very short period of time, basically a shorter amount of time than it takes the Call Server to end a session, the second application’s first request would arrive before the first application’s session ended and with the cookie referenced in the header, would make the VXML Server believe that the new request was made for the first application. VXML Server has a mechanism to recover from this exact situation. It waits for a certain period of time for the first application’s session to end and when it does, continues with the call to the second application normally. It logs this warning as a note to the administrator that the volume may be reaching its upper limits.
Severity: Very low since no call was adversely affected (any problem was averted by the error-correcting mechanism in the VXML Server).
|Recommended Action||If this warning appears very rarely, the administrator can safely ignore these warnings. If they appear more frequently, this would be an indication of high volume and the administrator should attempt to reduce the call volume to the machine.
Should it be found that the ICM script executed in between visits to VXML Server applications runs too quickly, a workaround to use would be to put a slight pause in this script to allow the first application’s session to end. Performing load tests on the system yields the optimal pause length.
|Associated CDETS #||None.|