com.audium.server.MultipleThreadException issues

[Ron Nelson]

I've recently developed a new CVP application, which uses a custom decision element to make two synchronous web service calls, followed by an series of audio prompts. 

The call occasionally ends abruptly.  It seems to coincide when the first of the two webservice calls takes some time (longer than 3 seconds) to receive the response.  This delay isn't normal expected behavior, however I don't think it's directly what's causing the issue.  The log indicates that the call flows through to whichever element is next and then receives the error, disconnecting the call from cvp and dropping it back to the ICM environment.

Can anyone point me in the right direction to better analyze what's happening in the flow to resolve the issue? Also is there some documentation on this specific exception somewhere.  We're using cvp8.5 at the moment.

Any help would be great!

[janinegraves · Accepted solution]

It could well be that the gateway is timing out and throwing an event -

but that would usually be logged as an error.badfetch event.

If this is the case, then you should set the VoiceXML Property named

fetchtimeout to a value such as 20s - do this in the Audio element

immediately before your web service calls. The gateway will revert back

to its default 'http client response timeout' when the next voice

element executes.

You should also set the VoiceXML Property named fetchaudio to a value

that points to a URI of an audio file to play during the delay.

[Ron Nelson]

I will give that a shot.  This application is called by sub dialogue invoke, therefore, do I need to set the fetchtimeout in the calling app? or insert an audio with silence prior to this and set the fetchtimeout there?

Is the fetchaudio used to play a sound like the percolating sound during the delay?

[hemal.mehta]

What is the timeout set in the web service code ?

Hemal

[janinegraves]

When you execute a Subdialog Invoke - it sends a VXML page to the

gateway to invoke the subdialog application.

I'm pretty sure that if you set the fetchtimeout before executing the

SubdInvoke - that it would no longer be in effect while the gateway

executes the invoke. You'd have to set it *within *the SubdInvoke

element (and Studio doesn't let you do that).

So, you should set *fetchtimeout *in your Subdialog application.

Add an *Audio *element in the subd application right before going to the

webservice.

In this element

a) set the *fetchtimeout *and the *fetchaudio *in the settings tab.

b) you have to enter something in its audio tab, so either play

silence_.1_sec.wav (it's in the en-us/sys directory) or play a short

message.

Yes, the fetchaudio is where you can specify to play the percolating

sound, or some other music. It has to be a full http string so the

gateway can retrieve and cache it.

There's also a VXML property named fetchaudiodelay that you can set to

*2s *so the fetchaudio music doesn't start playing unless there's been a

2second delay.

c) The important thing is that you're telling the gateway not to 'time

out' and to play filler music to the caller (which will be interrupted

as soon as the next vxml page is sent to the gateway).

d) I'm not sure this will solve your problem - as the error when the

gateway times out is error.badfetch --- but, it's important to have

these VoiceXML Properties set anyway.

e) As Hemal mentioned, you should check that your webservice timeout is

long enough to accommodate for the longest delay that might occur.

Janine

[janinegraves]

Hi Ron,

I just looked at the SubdialogInvoke element in Studio and I see that you CAN set the VoiceXML Properties within it.

So, you can set fetchtimeout, fetchaudio, and fetchaudiodelay in the SubdialogInvoke element. See the snapshot below.

BUT - if your subdialog app speaks to the caller before (or after) going to the webservice - then timeouts go back to the gateway default unless you also set them in that Audio element.

[Ron Nelson]

The receiveTimeout setting is at 60000 millis and connection is at 30000, so I think they're plenty long.  I'm trying a couple of the items that Janine Graves mentioned and we'll see what happens.

[Ron Nelson]

would it also work to set it in the root doc settings ?

[janinegraves]

Usually you want the *fetchtimeout *that's in the root document to be

*10s *(or shorter?) so you know that the application is progressing

smoothly.

It's only *immediately *before you perform a slow back-end interaction

that you want to temporarily set the *fetchtimeout to be large (60s*).

Then after the slow web service, the next VXML page that goes to the

gateway (*audio element *or Menu or Digits or Form, etc) causes the

*fetchtimeout *to revert to that in the root document.

The fetchaudio and fetchaudiodelay can definitely be put into the root

document.

Janine

[janinegraves]

Also, in the main application (that has the Subdialog_Invoke element

within it) -

Under *Project / Properties / Call Studio / General *-

ensure that the Session Timeout is long enough for the entire

subdialog application to execute

I usually set it to 3 or 5 Minutes - don't leave it at 30 minutes!

It's an inactivity timer - for a 'hung' license. Each voice element (eg,

audio, menu, digits, form, subdialog_invoke) has that amount of time to

complete before VXML Server frees the license because it assumes the

call's gone back to ICM.

So it has to be long enough for the entire Subdialog application to

complete.