Avaya Aura(r) Orchestration Designer
Version: 7.1 (7.1.0.1202) Build id: 201604141446


I have two root modules in my application each set with a different logging level

Modules:
Dispatch - ddlog4j.properties set to ERROR level logging
DispatchDebug - ddlog4j.properties set to DEBUG level logging



Our production calls are going into the Dispatch module while a backdoor number is going into the DispatchDebug module
This is so that production calls will only log at the ERROR level and the backdoor calls will log at the DEBUG level.


It seems that the production calls are logging correctly at the ERROR level until we call into the backdoor number. At which point some of the production calls start logging at the DEBUG level for a while. This does not seem to be permanent until we call in again.
Could the ddlog4j settings in DispatchDebug take affect for calls coming in on Dispatch after DispatchDebug is called? Could this crossover effect be caused by some variables in memory that are overwritten? If so, is there a way to prevent this?

I don't quite get the structure of your app but here is the how it works.The ddlog4j properties are loaded once in the OD session object. All the modules that are executed in the same session (per call) would use the same properties. The file is first loaded when the session starts in the main app.

I also thought that the dtlog4j was loaded for each call and only affects that call but I tested the same scenario on our dev system. When one version of the dtlog4j is loaded for a specific call and another dtlog4j is loaded for a second call it seems like the setting for the second dtlog4j take effect for the first call with is still taking place. It seems like two calls are accessing and modifying the same session object. Can you tell me what could be causing this and if there is a fix?

That's not possible. We've never had this problem unless the modules are not on the same app server. All the modules must share the same session object on the same app server. Also, on the same app server, the scertcommon jar is deployed in only the Tomcat/lib directory. You can trace the session id in the trace.log to see what is going on. There should be only one aggregated trace.log which lives in the main app. If you see multiple trace.log files, that's a sign of problem with the deployment.

Just to confirm. I want to use two seperate dtjlog4j.properties files. One for each of the two modules that can be called. Both on the same app server. Are you saying that is not possible ?

As I said earlier, OD loads the log4j properties into the SCESession object at the start of the session, and the session object is shared across all the modules. All the logs are aggregated into one log file under the main app. You can only force changing the properties by using custom code in a module but we don't support it.