We are having an issue when porting one of our applications over to OD7.1/EP7. The problem seems to be with catching an exception from IC, when trying to execute a "GetVDU Fields" operation.
The "GetVDU Fields" item is surrounded by a try/catch block, however the exception is ignored and the application drops the call abruptly (session is lost). I am attaching the errors from both sides, the OD7 application and the JVM (WebLogic 12c server), plus a snippet of the script in question.
Note that this exact same error is thrown in our OD6 environment, but the try/catch code handle it how it is supposed to, so the application continues processing normally.

---

OD7.1 / Application side error:

22/03/2017 16:15:33:094  INFO - r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170:/WFMain : Executing IPluggableExecutable com.avaya.sce.ic.ui.icConnector : GetVDU

22/03/2017 16:15:33:094 DEBUG - r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170:/WFMain : ICCommand.execute:  Talking to ICC using URL: http://10.248.11.105:7100/icconnector/RequestWebID

22/03/2017 16:15:33:095 DEBUG - r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170:/WFMain : ICCommand.execute:  setting session cookie to r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170:/WFMain

22/03/2017 16:15:33:098  INFO - r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170:/WFMain : Sending to ICC: http://10.248.11.105:7100/icconnector/ICConnectorWebServer?reqid=2-785&timeout=8000&cmdType=GetVDU&vdu_id=58d2db5e000000000af8127823340002&fields=%22TF_060_TASK_NAME%22%7C%22TF_180_IVR_ID%22%7C%22TF_240_IVR_TO_IVR%22&channel=79201&issip=0

22/03/2017 16:15:33:116  INFO - r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170:/WFMain : VRUSM response: responseType=getvdu.response&reqID=2-785&errorMsg=No value in EDU exists for TF_060_TASK_NAME

22/03/2017 16:15:33:116  INFO - r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170:/WFMain : error in VRUSM response:No value in EDU exists for TF_060_TASK_NAME

22/03/2017 16:15:33:129  INFO - r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170:/WFMain : HTTP Session lost removing SCESession r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170

22/03/2017 16:15:33:129  INFO - r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170:/WFMain : SCESession Removed

22/03/2017 16:15:33:129 DEBUG - r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170:/WFMain : Removing 1 session stack frames.

22/03/2017 16:15:33:129  INFO - r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170:/WFMain : ** Popped Stack Frame [/WFMain]

---

Weblogic / JVM error:

com.avaya.sce.runtimecommon.SCERuntimeException: Runtime Error, session lost while application was executing in FatalError

Runtime Error, session lost while application was executing in FatalError

com.avaya.sce.runtimecommon.SCERuntimeException: Runtime Error, session lost while application was executing in FatalError

Runtime Error, session lost while application was executing in FatalError

EXCEPTION> 

java.lang.NullPointerException

        at com.avaya.sce.runtimecommon.SCESession.findSession(SCESession.java:290)

        at com.avaya.sce.runtime.AvayaSessionTerminationServlet.requestHandler(AvayaSessionTerminationServlet.java:50)

        at com.avaya.sce.runtime.AvayaSessionTerminationServlet.doGet(AvayaSessionTerminationServlet.java:33)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)

        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:286)

        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:260)

        at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:137)

        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:350)

        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:247)

        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3650)

        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3620)

        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:326)

        at weblogic.security.service.SecurityManager.runAsForUserCode(SecurityManager.java:196)

        at weblogic.servlet.provider.WlsSecurityProvider.runAsForUserCode(WlsSecurityProvider.java:203)

        at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:71)

        at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2423)

        at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2280)

        at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2258)

        at weblogic.servlet.internal.ServletRequestImpl.runInternal(ServletRequestImpl.java:1626)

        at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1586)

        at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:270)

        at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)

        at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)

        at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)

        at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)

        at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:617)

        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:397)

        at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)

The trace line below indicates that the VXI (Voice Browser) is closing the HTTP session between the browser and the application server. Likely cause is a fetch timeout that is not handled.

	22/03/2017 16:15:33:129  INFO - r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170:/WFMain : HTTP Session lost removing SCESession r9v3qO-pZTI0B8RAdnmOi8NwxSZRBKcDhw2CRGipeqIEohi6buJv!-391791513!1490213728170

The thing to do is look at the session slot log on the MPP for a failing condition to see what the browser thinks is happening.

Hi Ross,

I just checked the fetch timeout on the MPP and it is 15 seconds, our call is about 8 seconds; same value as our 6.x system. We are also catching these fetch timeouts in the appRoot node, here's a complete trace from a failing call where you can see the error handlers plus a screenshot of the appRoot node.

We're still wondering why it only happens on 7.1.

appRoot node attached.

That is why we need to see the mpp session slot for the VXI. Then code that is executing is invoked when the VXI decides to end the HTTP session. The question is why did the VXI decide to do this?

Ross,

Please see the attached session slot log set to finest.

This does not look right. Did you follow the attached steps? The session slot you provided looks like the session manager and not the VXI.

You are correct, that was the SessMgr log. Here's the VB file.

When the log starts the VXI is already trying to fetch /WFMain/FatalError in a look and getting Error 500. The entire logis just looping. At some point the VXI detects this and kills the session.

Need to see what happens prior to this.

I did another test, this time I cleared all the logs and placed a call. There are no other calls being placed into this mpp but mine, some of the files seem formatted differently from the rest.

What I see is this:

Start -> Starting (HTTP 500, error.badfetch.http.500) -> Error2 (HTTP 500, error.badfetch.http.500) -> fatalError (HTTP 500, error.badfetch.http.500)...

Nothing other that the Start page loads. I would say this is a configuration error or something. Check the standard out for the application server and etc.

Hi Ross,

Even after opening a ticket with Avaya support, they still sent us back here for help as they only support the platform. I need to revisit this topic which is still an issue, I had to stop working on it due to other priorities. Instead of trying to troubleshoot our entire application, I was able to isolate the problem to just the "GetVDUFields" IC node. Let me restate the original problem:

1. When we take an existing production application originally created using OD6, and then import it into OD7, we notice that OD7 does a number of updates to the code since it detects that it was built with the older version.

2. Once the OD7 updates complete (and we see no errors), we can now proceed to export the application again for deployment.

3. When the new export completes (again, no errors), we upload the .war file to our application server and deploy it as usual.

4. Once we place a test call into this newly ported application, as soon as the "GetVDUFields" executes, the application throws an error and the system plays the technical difficulties message (file:///opt/Avaya/ExperiencePortal/MPP/web/handlers/sysError.wav).


We see none of these issues if we create a brand new application flow in OD7, the problem seems to be with the "importing process" from OD6 into OD7. To further aid in troubleshooting this issue, I went ahead and created a very simple flow which just calls "GetVDUFields" and then returns, and interestingly enough the issue was reproduced, so it is not just with our application.

I am attaching a screenshot of the test flow I used and also the session slot log, where we can see some errors when the session is terminated.

Can you also post the matching OD trace.log and I will take a "fresh" look at this.

Here' it is... you should be able to reproduce the issue, if you have both OD6 and OD7 to recreate this simple flow.

Did you have "showcaughtexceptions" enabled in the ddrt.properties? I will see what I can do here to reproduce. I do not have access to an IC system so I am not sure I can actually create a local test case.