NoSuchElementException

[muzicman61]

First post, so I hope I am placing it the correct forum.  I get the following error in my ErrorLog folder for my CVP app.  I'm trying to find out where the full log is.  Where can I find these "26 more" lines of the debug log?

WW.X.YY.ZZ.1590704235019.1329604.CCCServiceSales,05/28/2020 17:18:09.446, The error was: A built-in element encountered an exception of type java.util.NoSuchElementException. The root cause was: java.util.NoSuchElementException
com.audium.server.AudiumException: A built-in element encountered an exception of type java.util.NoSuchElementException.
at com.audium.server.voiceElement.VoiceElementBase.getVoiceElementResult(VoiceElementBase.java:773)
at com.audium.server.voiceElement.VoiceElementBase.service(VoiceElementBase.java:519)
at com.audium.server.controller.Controller.goToVoiceElement(Controller.java:4246)
at com.audium.server.controller.Controller.doPost(Controller.java:1127)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:528)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:798)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:810)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)
Caused by: java.util.NoSuchElementException
at java.util.StringTokenizer.nextToken(Unknown Source)
at com.audium.server.voiceElement.form.MFoundationForm.addXmlBody(MFoundationForm.java:1003)
at com.audium.server.voiceElement.VoiceElementBase.getVoiceElementResult(VoiceElementBase.java:746)
... 26 more

[bill.king1]

Are you using standard elements with this or is this some custom Java? What version of CVP? What shows in the application log when the error hits?

[janinegraves]

As Bill mentioned, look or post your Activity Log - it'll show you which element is causing the exception. It looks like it's coming from a Form element (I see MFoundationForm near the bottom of the stack trace).
The error is a standard java exception (google it) about iterating past the end of an iterable list.

I haven't seen that exception with Cisco's Form element - but there are many repeatable settings to which this might apply.

Also, perhaps you're using a 'Dynamic Configuration' (custom java code) to configure the element - look in the General tab of the element
Can you post a screenshot of the General tab and the Settings tab also?

Helpful if you can also post what version of CVP/Studio this was written for. And what version it's running on.
Also - are you using Nuance speech reco? Or DTMF only?
The more info the easier it'll be to help you.

[cid:f24f8eef-16b8-48d3-8060-e2a4eabc7dba]

[muzicman61]

Thanks for both your replies.  I didn't include the CVP info or anything else because I simply wanted to no where the rest of the log file was at so i could troubleshoot this on my own and hopefully learn something.  The "26 more"...

But none the less I appreciate your help.  To answer your questions...

I have no idea what version the app was originally written in.  I'm currently using Call Studio 11.6 and we do not have any Nuance servers.  The activity log doesn't do much help.

10.x.yy.zz.1590961744202.1424420.CCCServiceSales,05/31/2020 16:49:28.312,CCC_SERV_CLAIMS_MENU,enter,
10.x.yy.zz.1590961744202.1424420.CCCServiceSales,05/31/2020 16:49:34.193,CCC_SERV_CLAIMS_MENU,element,error,
10.x.yy.zz.1590961744202.1424420.CCCServiceSales,05/31/2020 16:49:34.193,CCC_SERV_CLAIMS_MENU,exit,
10.x.yy.zz.1590961744202.1424420.CCCServiceSales,05/31/2020 16:49:34.193,CCC_SERV_CLAIMS_MENU,exit,

I am curious why I have two exit entries.

The element itself does not use any custom java but I suspect the error could be coming from custom java in the decision element before or the decision element after this element.

There is nothing in the General Tab.  Here's the settings tab.

[bill.king1]

If it were me, to troubleshoot I would have a call go through the node before this and then to something basic like an audio node and then out to UCCE so that you know for sure if it is tied to the custom Java vs. this node.

If it is tied to this specific standard element, as a troubleshooting step I'd pull a fresh one over and use (don't copy and paste) the same values into the new one, just in case there's something in that "standard" node.

[muzicman61]

Thanks. Unfortunately this doesn't happen for every call and I haven't even been able to reproduce the error in our Test environment.  In fact, out of 5833 calls on one server, it only occurred 4 times.

My thought was to add a VXML event and capture the lastException value. Maybe that would actually give me the "26 more... " lines of the exception or something more to point me in a better direction.

[janinegraves]

One thing I notice is that in the Form element, to accept the * key you should use backslash-star \*, not forward slash as in your snapshot.
This is actually a java exception (you know that because in the error log, it displays the long stack trace) - so it's due to VxmlServer executing the app (not due the voice browser, hence not a VxmlEvent).

If you catch the exceptions (whether you catch Java Exceptions or VXML Events), you'll actually get LESS information in the lastException variables than you currently see in the error log. And you won't have anything in the error log.

Do you know what the element before the Form is doing? Do you have its java code available?

[janinegraves]

Can you try calling into the app and pressing the DTMF * key? See if this triggers the error?
Since the slash is incorrect, it's possible that if the caller presses * that the VVB accepts it (even though it's configured with the wrong direction slash) and returns * to VXML Server. VxmlServer then needs to determine what to do with *, but VXML Server has /* in its list - so perhaps VxmlServer throws the NoSuchElement event only when callers enter the * key???

[janinegraves]

Do you have IOS VXML GW? Or VVB?
I only have VVB 11.6 and I'm trying to generate your exception, but the VVB is  much more accepting of weird stuff than the IOS VXML GW.

So for example, /* or * or \* all work in the form element to allow caller to enter star key. But, I don't think IOS VXML GW is nearly as forgiving.

Another place where I've seen weird results is if any of your DTMF-Keypress settings have a space after the entry like '1 '  (without the quotes) - this is obviously very hard to spot as it's a blank space. But you can double-click on the keypress entry and  see if your cursor displays wider than just the one dtmf entry.

[muzicman61]

Thanks Janine... I question the /* as well, but I have never found a log entry that failed when the caller entered * as the menu option.  That said, I have tried testing using * as the input but could not get it to fail.  The element prior to this element is a decision element that does use java code.  There are actually several element decisions throughout the app that could lead to this element.  I can say that it is just a cluster of if/else blocks that set a session variable based on a few other session variables and the DTMF input from the caller.  Pretty straight forward Java and the failures only have occur when the code returns "CLAIMS".  Here is the relevant snipit of code.

			else if  (elementAPI.getElementData("CCC_SERV_NOVM_MM", "value").equals("2"))
			{
				if (sLanguage.equalsIgnoreCase("S"))
				{
					if(natBridge.equals("yes")){
						elementAPI.setSessionData("calltype", "CCC_NB_NOVM_MM_SP_O2");
					}
					else{
						elementAPI.setSessionData("calltype", "CCC_AF_NOVM_MM_SP_O2");
					}
	
				}
				else{
					
					if(natBridge.equals("yes")){
						elementAPI.setSessionData("calltype", "CCC_NB_NOVM_MM_O2");
					}
					else{
						elementAPI.setSessionData("calltype", "CCC_AF_NOVM_MM_O2");
						elementAPI.setSessionData("call_destination_path", "Claims");
					}

				}
				
				return "CLAIMS";
			}

[janinegraves]

what does your custom java code return if none of the if statements are satisfied?

[janinegraves]

Also, I think that if you test you'll see that any DTMF key is accepted in your Form element (that's what I observed on mine with /*). So could it be that your code is running into an error when the caller enters something that's not specifically configured in the settings tab of your Form element?

[janinegraves]

Hi Rob, Did you ever figure this out?

[muzicman61]

Haha... you've revealed my true identity!  😎

Still working on it.  But been busy on other assignments.

So if the caller enters nothing or there is no match or it somehow hits the Catch exception, it returns "0_Out".  I've not seen a failure in those situations.  Only when the results returns "CLAIMS".

When I see the failure in the logs, the previous element always show a successful utterance of typically 1,2,4, or 9.  I've not found a failure where they entered * and that's probably because if they entered * they would not end up at this failing element.

Appreciate your help on this but probably going to have to put it on the back burner for now as more critical work has hit my plate.  If I come up with anything I will be sure to update this thread.

[muzicman61]

I also checked for a space in the DTMF keypress but didn't find one. And we are now using VBB.