We have a call where the log records were repeated more than 21 times for the same caller. Do you have any idea what would cause this?

Thank you,
Michael

I am not aware of any issue like that. Are you talking about the OD trace.log? Could you give some sample of the logs?

Sure, I doubt there's anything in the logs, but see the attachment. My suspicion is it's something to do with the Tomcat logging framework. The particular windows system has both Tomcat 6 and Tomcat 7 installed (different port numbers), with both OD 6.x and 7.x installed into the appropriate Tomcat instances. This is a fairly "normal" setup, but we haven't experienced this issue anywhere else. Was hoping that there might be something you folks could shed some light on, but I'm not overly optimistic LOL

The excerpt from the logs is for a specific caller. The logs show lots of activity over a period of a few minutes. In reality, if they actually did all of this activity, they would've been on the line 40-45 minutes. Also, after talking with the caller, they only "confirmed" 2 assessment numbers, not the 21+ that's displayed in the logs.

I've only included the particular session that is causing the confusion. If you'd like the entire log, I can attach that as well. I'm currently going through all of the logs for the other applications in an effort to see if this has happened anywhere else.

Thanks for help.
Michael

I am not sure what to look for there. This file only shows me one call for the duration of little less than 6 minute. It seems normal.

6 seconds to go through that many prompts isn't normal at all. I've attached the entire log file for that day so you can see the other calls as well. Based on our testing, it should take at least 6 minutes to get through the flow just once. The logs show this caller going through the flow multiple times. In reality (after talking to the caller), they only went through the flow twice.

Unlike the first log snippet you sent (that was a normal call that spends 6 min as I said), I saw in this day worth log that there are a lot of calls with the following log pattern for the very first call in the log. The call basically didn't get to the GetCallerData node then the session timed out. You may need to find out why the GetCallerData never got called from the platform(voice browser) side.


11/07/2016 00:00:29:152 INFO - 66AB98E2B583CFC00C8A5276509AAFD5:/AARC : SCESession bound to HttpSession 66AB98E2B583CFC00C8A5276509AAFD5
......
235:<submit next="GetCallerData?___DDSESSIONID=66AB98E2B583CFC00C8A5276509AAFD5%3A%2FAARC" namelist="session___aai session___ani session___dnis session___protocolname session___protocolversion session___uui session___calltag session___channel session___vpcalledextension session___vpcoveragereason session___vpcoveragetype session___vprdnis redirectinfo___uri redirectinfo___presentationinfo redirectinfo___screeninginfo redirectinfo___reason session___sharedmode shareduui___id shareduui___value session___sessionlabel _sipcallid session___mediatype session___videoenabled session___videocodec session___videoformat session___videowidth session___videoheight session___videofps session___videobitrate session___videonearfmtp session___videofarfmtp session___ucid session___conversefirst session___conversesecond" method="post"/>
236:</block>
237:</form>
238:</vxml>
239:
.......
11/07/2016 00:31:29:165 INFO - 66AB98E2B583CFC00C8A5276509AAFD5:/AARC : HTTP Session lost removing SCESession 66AB98E2B583CFC00C8A5276509AAFD5

We noticed that too.. we're reaching out to the customer to see if they have some sort of keep alive process running... checking the tomcat manager shows 10-20 open sessions for each OD application, and the AEP shows 5-10 calls.

Regarding that call, based on the number of times the caller "went through the app", they should have taken about 40-45 minutes, not the 6 minutes in the log. There's a lot of time stamps that are milliseconds from each other that don't make sense. I'm thinking it may be something else outside of the applications. I'm going through other logs now to see if this issue happened elsewhere.

Anyway, thanks for your help. :)
Michael