This is how we have done it. The runtimeSupport files are copied in a directory that is then added as an external library.

This particular WebSphere is in a cluster, and has the libraries declared as external. We are checking with WS support, but can either of these be a problem?

That seems like a Axis2 jar missing (MTOM). Maybe you have the axis2 jars inside your app, or have mismatched versions?

It is not set on the prompt and collect node, but on the prompt.

Inside the prompt there is a tab called "Prompt Main", there there is a list of prompt levels, you should have only one. Click on the prompt level and look at the properties, set the property "timeout" to the number of seconds/milliseconds you want.

We have the classloader in every app, if we didn't it wouldn't even validate, because it would have no scertcommon.

How can we check if the system really is using the same classloader?

We have a multicluster classloader, and that means that the runtimeSupport files are not on the global lib/ext, but on a shared library in a different directory, that is included as a shared library on all the modules we deploy. If this was the issue, would there be a way to write the current classpath of the app and the module, to check if it is OK? (A system property, Classloader.getSomething...?)

We have double checked and it is SP3. The trace log is turned off, attached the stdout.

Upon restarting the WAS the problem goes away, but comes back a few days later, on peak traffic day.

Sorry about the mismatch on the version number. The full name of the version we are using is Service Pack 3 (Release 5.1.0.17.02). According to https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_orchestration_designer/releases/dialog_designer_5_1/index.gsp that is the latest version.

Hi.

We have an app with a Weblogic server, the app works fine normally but under very heavy load we start getting threads stuck with the following log:

Thread-89 "[STUCK] ExecuteThread: '74' for queue: 'weblogic.kernel.Default (self-tuning)'" <alive, suspended, blocked, priority=1, DAEMON> {

    -- Blocked trying to get lock: com.avaya.runtimecommon.platforms.vp.PlatformParams@1063b5b8[fat lock]

    com.avaya.runtimecommon.platforms.vp.PlatformParams.checkForUpdate(PlatformParams.java:30)

    com.avaya.sce.runtimecommon.SCESession.getSession(SCESession.java:240)

From what we know this is because the thread starts waiting on a synchronized block (hence the fat lock). Once this happens all threads start blocking behind this one, and the system becomes deadlocked.

This is with DD5.00.17. We have spoken with Webogic support and they say that we are causing these threads to get stuck. The particular app we have has no VP configurable variables, could we use this to our advantage to bypass this checkForUpdate?

Is there anything that we can do to avoid this lock?
Could this be a file locking issue?

Thanks

I have checked the same with a different IVR using Tomcat 6 + OD6SP1 and it seems the same thing happens.

Newer version, fixes a bug where zero y said a "cero de pesos", so that it says "cero pesos" as it should.

Sometimes when the audios (wavs) cannot be found the MPP tries to use a TTS to reproduce what was in the audio (by using metadata) and you get that message. Maybe the audios are unavailable for a short while, as they redeploy?

Hi.

We have an application that calls a module (via Subdialog) on Websphere 8.5. The invocation seems to work fine, but upon reviewing the report nodes that are sent from within the modules are not being written to the database. That is, the reports from the main app are written just fine, but the reports from the modules are not written. If we change ddrt.properties to report the log locally, then the reports are written in the local file, but still not on the database. Is there a setting that needs to be changed on the WS file? on the ddlog4j files?

Thanks

Hi.

We have just tried doing this with WebSphere 8 and the local call just did not happen. The call was hung up and there are no errors on the logs. Should this work, or this is a thing being worked on?