Cchetty: 1 revision

2011-09-09T06:57:07Z

1 revision

← Older revision

Revision as of 06:57, 9 September 2011

Sansahoo: /* Calls are aborted due to number of sessions configured on the application reaching the maximum limit */

2010-04-12T11:31:26Z

Calls are aborted due to number of sessions configured on the application reaching the maximum limit

New page

== Calls are aborted due to number of sessions configured on the application reaching the maximum limit ==

{| border="1"
|-
! '''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.

|-

! '''Recommended Action'''
|

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.

2) If the number of sessions are not sufficient to handle the incoming calls, then the new calls will get
abandoned. Try increasing the number of sessions and see if this resolves the issue.
|-

! '''Release'''
| Release 4.5.2
|-
! '''Associated CDETS #'''
| None.
|-
|}

[[Category:Unified CCX, Release 8.0]]

Calls are failing with ApplicationMaxSessionsException because there are not enough sessions created for an ICM application in IPIVR - Revision history

Cchetty: 1 revision

Sansahoo: /* Calls are aborted due to number of sessions configured on the application reaching the maximum limit */