Calls are failing with ApplicationMaxSessionsException because there are not enough sessions created for an ICM application in IPIVR
(→Calls are aborted due to number of sessions configured on the application reaching the maximum limit)
Newer edit →
Revision as of 11:31, 12 April 2010
Calls are aborted due to number of sessions configured on the application reaching the maximum limit
|Problem Summary||Calls are aborted due to number of sessions configured on the application reaching the maximum limit.|
|Error Message||Calls are aborted due to ApplicationMaxSessionsException.|
|Possible Cause|| Check if there are following exceptions in the MIVR logs :
922377: Jun 26 15:42:34.593 GMT+800 %MIVR-SS_TEL-7-UNK:Call.aborted (com.cisco.app.ApplicationMaxSessionsException: max of 67 reached for application 'InComing Call') JTAPICallContact[id=8610,implId=15319139/3,inbound=true, Appname=InComing Call,task=337000031606,session=343000008145,seqnum=0,cn=88008,dn=88008,cgn=013376039680,ani=null, dnis=null,clid=null,atype=REDIRECT,lrd=75100,ocn=75100,route=RP[num=88008],TP=82034]
This can be the case when 1) a call is over but the application continue processing (like for DB cleanup or other similar tasks). 2) Basically, based on how customer built their application, they need to account for the fact that it might run longer after the call is over at which point the ports and media channels are released and can be re-used by the system. In this case, they are but when it comes to triggering the application, there is no more sessions available for it since the other one is still running.
1) It could be that there are some stuck sessions in the system, due to which sessions are not getting released for the new calls. To confirm this, check the application tasks in RTR reports to see if there are any sessions stuck for a long duration.
Also, there could be following deadlock exceptions in the logs, due to a deadlock situation while executing step :StepHost which is called while executing some custom Java Method in the IVR script.
190026: ÁùÔÂ 30 12:41:48.958 GMT+800 %MIVR-MGR_MGR-0-THREADS_DUMP:Java Virtual Machine Threads Dump: Message=null,Exception=com.cisco.lang.DeadlockError: potential deadlock detected
In the above case, the script is stuck inside customer-defined code which is not returning the control back to UCCX. As such, the task will hang there and the application session and the task instance will never be released.
The customer should investigate their code to figure out why they are blocking.
Correct the script and try out the calls.
|Associated CDETS #||None.|