>>>This happens about 2% of the time and happens to two custom elements that both connect to a webservice.

Is your element thread-safe? I assume you are aware of the standard warning in custom elements:

WARNING: only static variables allowed in the class. Multiple invocations can over-write class variables.

Regards,
Geoff

Also check the application\XXX\logs\ErrorLog directory. You may see an exception there, if one is thrown that you have not caught.


Regards,
Geoff

Rick,

If the custom action element works fine in testing but occasionally fails under load, you have to suspect one of two things. (a) you are getting into memory problems in the VXML server or (b) your element is not fully protected during multiple simultaneous executions.

If things go well for a while after a server restart and only then you start to see occasional problems, you might suspect (a).

For (a) you can increase the memory assigned to the stack and the heap of the JVM through the java options in the registry. I try to give this server as much as the physical system, and the other processes running on the box, allow.

If you suspect (b), have a look at the timestamp in the activity log when a problem occurs and check around the activity log to see if your custom action element is being invoked by another call at exactly the same time.

When you write “There are no multithreaded operations in my script.” that was not the point I was trying to make. The whole system is multi-threaded due to calls arriving from the PSTN, and two calls can be accessing the custom action element at exactly the same time. The warning that I quoted (originally in Audium samples) is telling you not to make non-static global variables in the class.

Session variables are on the thread of the call, so are completely safe.

If the doAction() method is one single function, you should never have issues.

But if doAction() calls another method passing parameters to that method, and that method is required to set a number of pieces of data that doAction() wants to access in order to (typically) set some session variables the application uses, take care how you do this.

Regards,
Geoff

You missed the fact that Rick said he was catching exceptions and writing to the activity log.

Check back:

“I have a try catch around the entire doAction method and I log any exceptions to the activity log.“

Regards,
Geoff

Richard,

The fact that your element completes is saying that the applicaiton did not encounter a fatal unhandled exception or even more probable is that it did not throw the appropriate exception to audium services..

You mentioned that your doAction method was surrounded in a try/catch. This method throws an audium exception when encountering an error. I'm wondering if this may be contributing to the way that element is wrapping itself up. Perhaps you could try bringing that try/catch inside the method and only surrouding the object methods that need to be.

I'm no seasoned expert but this seems plausable.

-Ryan

________________________________
From: Cisco Developer Community Forums [cdicuser@developer.cisco.com]
Sent: Tuesday, February 21, 2012 8:57 AM
To: cdicuser@developer.cisco.com
Subject: New Message from Richard Rhinehart in Customer Voice Portal (CVP) - CVP - All Versions: RE: CVP Error

Richard Rhinehart has created a new message in the forum "CVP - All Versions":

--------------------------------------------------------------
I'm still waiting for the Tomcat Logs but thought I'd add this.

My initial post was a bit misleading towards the end.

"I receive no more logging from my element which there should be several more lines, and the element ends without error. It calls the next element which is a decision element and that element errors out."

I should have stated.

No more logging from the ActIsSSNValid element. There should be whether successful or failure. The next element runs and reaches an error exit state. It calls the next element which is not listed in my log above which follows an error route and calls a custom element that sends and email and logs to the database that there was an error.(the error from the decision node because certain lookup values weren't filled... not a real error) In this case my session "Error" variable is not filled and logs the default value which I set to null. So everything else runs accordingly its as if it just skips 80% of one element and then the studio application runs to completion.
--
To respond to this post, please click the following link:

<http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/5185622>

or simply reply to this email.

2 things about changing the logging cache:

1. To enable real-time activity log caching, go to Project > Properties > General - select the ActivityLogger and then press Edit, and Edit again.
Find the portion near the bottom where it has

<cache>
<per_call kb_limit="50" allocate="once"/>
</cache>

The documentation says you can just comment out these 3 lines (enclose between <!-- and --> tags ) and then deploy/update and the system will log in 'real time'.

(This could be done directly on the vxml server in the file applications/appname/data/application/ActivityLogConfig.xml -- then run the update script)

2. But Geoff, the fact that the logs show a missing audio file (error.badfetch.http) a few elements after the Audio element that tried to play it, is not a buffering issue. It's the way the VoiceXML Gateway works.

A Voice Browser never 'blocks' on playing audio (that is, it doesn't wait for it to be retrieved and played). It only 'blocks' on audio playback when it needs to also collect caller input.

An Audio element causes the voice browser (on the gateway) to hand off the http fetch and play request to other processes and then continue with an http request back to the VXML Server indicating it completed the Audio element successfully. This causes the activity log info to display success.

It's not until an element that collects caller input goes to the gateway, that the voice browser must wait for all pending play requests to complete. It's then that error.badfetch.http events finally occur.

This turns out to be a VXML issue, not a Cisco issue. Although, Cisco could (should?) provide a VXML Property to tell the gateway to 'block' on the playing of an audio.

Regards, Janine

 
Ok so here's another thought:
ex.GetMessage() that method right there is why you're not seeing the exception logged in the activity logger. Try ex.toString() that should give you something more useful.
 
For example, when I try ex.GetMessage() in some of my code, it returns nothing, whereas ex.toString() will give me a Java.NullPointerException or something like that
-Ryan