VXMLSession timeout

[phanivenigalla]

HI Janine,

I am seeing these errors a lot in error log

The error was: Another thread is currently working on this session.  This means the original thread took too long to complete what it was doing.  To prevent abnormal behaviour the original thread will exit immediately.  The call should not be affected.

com.audium.server.MultipleThreadException: Another thread is currently working on this session.  This means the original thread took too long to complete what it was doing.  To prevent abnormal behaviour the original thread will exit immediately.  The call should not be affected.

Also Session is not releasing quickly even call hung up.

This kind of behavior i didn't see when we use IOS browser. where as VVB i see these issues.

Anything need to look on application prospective.

Thanks,

Phani.

[janinegraves]

I haven't worked much with the VVB yet. Are you on 11.5 or 11.6?

Usually the timeout errors are generated by the vxml gateway when it's

waiting for the next vxml page from vxml server. This usually occurs

when your app is executing a 'slow' web service (WS) or DB call.   And

in that case, VXML Server needs to stop its DB/WS threadl and 'honor'

the error.badfetch from the gateway - that's the reason for the message

about a thread taking too long to complete.

Is this where you're seeing the errors? Are they occurring in WS/DB calls?

If so, you can assign the VoiceXML Property Name:fetchtimeout Value: 30s

in the audio or voice  element immediately prior to the DB or WS element.

And you can set a voicexml property so the gateway plays audio while

waiting: VoiceXML Property Name:fetchaudio Value: http://pathToAnAudioFile

If your seeing random exceptions, it's possible that you have to

increase the*VVB's equivalent of the http client response timeout *--

which is how long the gateway waits for any http response (whether from

vxml server or the media server).

Also, when you say the session isn't releasing - are you saying that the

vxml server license isn't released - or that the 'sessions ending' isn't

going to 0?

You can ignore 'sessions ending' - this port license should have been

freed by then. Sessions ending is just info for cleanup code, it goes

away after 60s.

You can see this when you execute the status.bat for appname/admin or

VxmlServer/admin.

[phanivenigalla]

This happening in WS call as well as when VB trying to play any audio just before WS Call.

We have 30 WS calls. I have given  fetchtimout 30secs, before WS call custom element and  httpConnectTimeout 10 and readTimout 15 secs given in Http properties,When i increase timeouts its holding the session longer time to release. This issue when the lot of calls in server. We don't have any audio to play while waiting to fetch WS resopse.

Some times i see sessions Waiting to End more than the Active calls, that scares me to VXML service crash.

[Gerry O'Rourke]

Phani,

The first thing I would check is if you have installed the latest ES on the VVB.

I had a number of issues that were corrected with the latest ES.

e.g. VVB 11.5 latest cumulative ES is 43

So you need ES1.27 (mandatory) and ES1.29

Then I would look at the logs on VVB

You can do this in real time (when making the calll using the below command).

# Find the current log file

file view activelog uccx/log/MIVR/Cisco001MIVR.index

# Tail the current log file (replace XX with the actual filename)

file tail activelog uccx/log/MIVR/Cisco001MIVR0XX.

Then maybe break down your application to try to determine exactly which part of the code is causing the error.

Is it using custom Java code? Is is using custom JavaScript?

Regards,

Gerry

[phanivenigalla]

Thanks Gerry,

Iits VVB 11.5 and ES43 . CVP 11.5 and ES12. But i still see those errors.what is these ES1.27 and ES 1.29 for?

Yes it custom java code.

[Gerry O'Rourke]

Phani,

ES27 is not going to fix your issue, but its a VM fix and is available on the VVB download page:

Sorry - you won't need ES29 as that is included in ES43

https://software.cisco.com/download/release.html?mdfid=286309853&flowid=80742&softwareid=286289787&release=11.5%281%29&relind=AVAILABLE&rellifecycle=&reltype=latest

Did you try reproducing the issue and looking at the VVB log files (with the details I showed you above)?

Gerry

[phanivenigalla]

Hi Janine,

We have strange issue, I use JAXWS client implementation for Web service calls.

I am giving the setting for ConnectTimeout and ReadTimeout as below

reqCtx.put(JAXWSProperties.CONNECT_TIMEOUT, connTimeout);

     reqCtx.put(JAXWSProperties.REQUEST_TIMEOUT, resTimeout);

When i run the test class from callstudio i see these paroperties works and i get the exceptions.

But when i call and try to do lookup from IVR, i observe this settings are overwritten by VXML JVM.

Can you please let me know what parameters need to set for this JAXWS implementation.

Thanks,

[janinegraves]

Paul Tindall - do you know the answer to this?

We have strange issue, I use JAXWS client implementation for Web service

calls.

I am giving the setting for ConnectTimeout and ReadTimeout as below

reqCtx.put(JAXWSProperties.CONNECT_TIMEOUT, connTimeout);

     reqCtx.put(JAXWSProperties.REQUEST_TIMEOUT, resTimeout);

When i run the test class from callstudio i see these paroperties works

and i get the exceptions.

But when i call and try to do lookup from IVR, i observe this settings

are overwritten by VXML JVM.

Can you please let me know what parameters need to set for this JAXWS

implementation.

[ptindall]

Did you try this?

import com.sun.xml.ws.client.BindingProviderProperties;

reqCtx.put(BindingProviderProperties.CONNECT_TIMEOUT, connTimeout);

[phanivenigalla]

Hi Paul,

Yes i tried this properties. What i observed was JAXWS and BinderProperties returns

BindingProviderProperties.CONNECT_TIMEOUT===com.sun.xml.internal.ws.connect.timeout

BindingProviderProperties.REQUEST_TIMEOUT===com.sun.xml.internal.ws.request.timeout

this is only works in eclipse studio. When it comes to VXML server these properties are not accepted.

Thanks,

Phani.

[ptindall]

I just tested BindingProviderProperties.REQUEST_TIMEOUT on a request to a non-existent IP address and it worked successfully.  The property name in my case was  REQUEST_TIMEOUT = "com.sun.xml.ws.request.timeout", not "com.sun.xml.internal..."

Paul

[phanivenigalla]

Hi Paul,

May i know or having document that VXML server not supported "com.sun.xml.internal.ws.request.timeout".

Thanks,

[ptindall]

Not aware of any documentation to that effect.  However, if you look in the standard web services element classes you'll find that connect timeout uses com.sun.xml.ws.connect.timeout rather than com.sun.xml.internal.ws.connect.timeout.