05-29-2020 09:42 AM
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
05-30-2020 06:43 AM
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?
05-31-2020 07:34 AM
06-01-2020 08:41 AM - edited 06-01-2020 08:42 AM
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.
06-01-2020 09:00 AM
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.
06-01-2020 09:15 AM - edited 06-01-2020 09:24 AM
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.
06-01-2020 09:53 AM
06-01-2020 09:57 AM
06-01-2020 10:11 AM
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.
06-01-2020 12:54 PM
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"; }
06-01-2020 12:59 PM
what does your custom java code return if none of the if statements are satisfied?
06-01-2020 01:02 PM
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?
06-02-2020 11:20 AM
Hi Rob, Did you ever figure this out?
06-02-2020 12:10 PM
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.
06-01-2020 12:55 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide