Script hangs on menu step

[thomascollins]

I've got a rather large script, but having trouble with one new section.  We calculate the expected wait time, create a variable for a prompt to play a specific announcement, and offer voicemail (press 1).  If they don't press 1, back on hold, wait X seconds, repeat, etc.

It loops through just fine about 30 times, but then it hangs on the Menu step.  No prompts, no hold music.  Doing a debug, you see it just stop on the Menu object.  No errors show up in the debug output.

We shouldn't be hitting the global max steps (it would terminate in that case right?).  Is there some other counter that could be hanging?

UCCX 8.0(2) SU2.

Thanks for looking...

Tom

[thomascollins]

Searching through the MIVR logs, it appears we are hitting a queue limit:

%MIVR-LIB_EVENT-5-TOO_LONG_IN_QUEUE:Event queue time exceeded:

However, I never see com.cisco.wfframework.obj.WFMaxExecutedStepsExceededException as referenced in this thread https://supportforums.cisco.com/thread/268273

Currently our Engine logs are set to Debugging.  Is this a different error, or am I hitting the max steps (1000)?  I've begun some script cleanup and made sure we don't have any infinite loops.  But I'd just like to confirm if this is indeed the 1000 steps issue, or some other queue time parameter.

[Graham Old]

Enterprise has a maximum queue time but I was not aware that CCX had one.

Try pushing your maximum step count up to 2000 and see if that makes any difference.

How long is 30 times around your delay loop taking?

Graham

[thomascollins]

We found the problem.  We tried changing the max steps to 2000, and it exhibited the same behavior at the same point.  It would loop through a few times, but always stop at this Menu step (even through it had previously looped through fine).

So in testing I re-created another UCCX Application, same script.  I couldn't reproduce the problem on this application, but I could on my original.  So I started to focus on the trigger.  Turns out my production trigger had

Override Media Termination = YES.  That worked fine for all our other applications.  But for this particular one it was causing a problem.  Setting Override Media Termination = NO fixes the problem. 

I opened a TAC case and they confirmed the expected behavior should be the same either way.  So this may be a defect.  But because we're running an old version they didn't want to investigate a defect without upgrading first -- which is on our radar but not right now.  So the workaround is fine.