cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
826
Views
5
Helpful
4
Replies

CVP unending loop in certain cases

harresh123
Level 1
Level 1

Hey Guys,

 

I have a few call studio apps where we make a subdialog http call to an external vxml application. All works good in an ideal scenario. However, in odd-ball scenarios where caller hangs up mid way and didn't give the VXML app time to process through the termination/clean-up logic, the voice browser results in unending loop trying to fetch the same file from vxml app over and over again. How can I prevent the voice browser from fetching these files over and over again. Is there a retry limit I could specify somewhere.

 

288908176: May 10 08:04:01.829 EST %MIVR-SS_VB-7-UNK:[CALLID=272CC20000010000000073870104D30A-165218418989812639] Browser.fetchVxml(): got IOException e=: Exception=java.io.IOException: Server returned HTTP response code: 500 for URL: http://xyz.company.com/xyzReset/CleanUp.aspx
288908199: May 10 08:04:01.830 EST %MIVR-SS_VB-7-UNK:[CALLID=272CC20000010000000073870104D30A-165218418989812639] VXMLDocumnet.loadbAndParse().aThread.run(): got vbe (VBEvent type) =error.badfetch: Error fetching req: http://xyz.company.com/xyzReset/CleanUp.aspx; nested exception is:
288908200: May 10 08:04:01.830 EST %MIVR-SS_VB-7-UNK:[CALLID=272CC20000010000000073870104D30A-165218418989812639] VXMLDocumnet.loadbAndParse().aThread.run() (throw vbe) thread (TimeoutThread_1652184241713_99979) end=1652184241830, time=117 state=ERROR
288908201: May 10 08:04:01.830 EST %MIVR-SS_VB-7-UNK:[CALLID=272CC20000010000000073870104D30A-165218418989812639] VXMLDocumnet.loadbAndParse(): fetching through aThread.run() returned with error, event= com.cisco.voicebrowser.VBEvent: error.badfetch: Error fetching req: http://xyz.company.com/xyzReset/CleanUp.aspx; nested exception is:
288908202: May 10 08:04:01.830 EST %MIVR-SS_VB-7-UNK:[CALLID=272CC20000010000000073870104D30A-165218418989812639] ContactInactiveException

4 Replies 4

janinegraves
Spotlight
Spotlight
I think this happened recently and the fix was to remove from the Root
Document the vxml property named fetchaudio, and instead to put that
into the Settings tab of whichever audio element precedes the web
service/DB calls.
Do you have fetchaudio in the root document
(Project/Properties/CallStudio/RootDoc?)

You may find this defect of interest as well.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi43753

Interesting. I do. Did you see similar thing in the logs too? A month back TAC suggested fetchtimeout to be specified in the root document as I wanted to keep the session wait for a little longer for the audio files to be fetched from the VXML app. 

It's ok to put  the fetchtimeout in the root document, but not the
fetchaudio. You can move the fetchaudio to the settings tab of a voice
element just before the slow steps in the app.