Hi

I have AAEP 7.1, AAOD 7.2, Tomcat 8.5.35, Java 1.8. I have a problem with ddconfig.xml. After adding the configuration in runtimeconfig, the configuration is stored in ddconfig.xml. Unfortunately, after restart tomcat(not every) the ddconfig.xml file is empty. Now I have secured against this by having a ddconfig backup and changing file permissions from 644 to 444. Has anyone had a similar problem and resolved it in another way? Something overwrites this file and I do not know why.


Thank you in advance!

It must be some external process that empties the file. OD does not do that.

It looks similar to this topic:
https://www.devconnectprogram.com/forums/posts/list/10051.page

In catalina.out after restart I have error:
Error saving configuration file
java.io.FileNotFoundException: /opt/tomcat/lib/ddconfig.xml (Permission denied)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(FileOutputStream.java:270)
at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
at java.io.FileOutputStream.<init>(FileOutputStream.java:162)
at com.avaya.sce.runtimecommon.config.impl.ApplicationConfigurationImpl.save(ApplicationConfigurationImpl.java:219)
at com.avaya.sce.runtimecommon.License.clearInvalidTimer(License.java:239)
at com.avaya.sce.runtimecommon.License.getInstance(License.java:163)
at com.avaya.sce.runtime.Entry.handleRequest(Entry.java:267)
at com.avaya.sce.runtime.AppDocument.processRequest(AppDocument.java:343)
at com.avaya.sce.runtime.SCEServlet.requestHandler(SCEServlet.java:247)
at com.avaya.sce.runtime.SCEServlet.doGet(SCEServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
at com.avaya.sce.runtime.Entry.service(Entry.java:52)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
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:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:800)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
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(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

It looks as if OD wanted to overwrite the configurations.
Reagrds

It may update the invalidlicensetimer parameter in the ddconfig.xml file but it should not erase other existing information. Can you check to see if there is a scertcommon<version>.jar somewhere else other than the Tomcat/lib directory?

Only in /home/cust

This looks odd. According to the exception, OD (some code in scertcommon jar) is trying to write the the file in /opt/Tomcat/lib but the scertcommon is in /home/cust. Typically, the jar file and the ddconfig.xml are in the same place.

We did not understand each other. You ask about extra place. In summary, the scertcommon<version>.jar have two locations:
1. /opt/tomcat/lib/
2. /home/cust/

Regards

Apparently we did not understand each other. Let me be more clear. There should be only one place for the scertcommon jar. It should be in the Tomcat/lib (aka common lib) directory.

OK, Right now I have the scertcommon<version>.jar only in /opt/tomcat/lib/. I deleted files from /opt/tomcat/work and /opt/tomcat/temp. Unfortunately, after tomcat restart, I still have the same problem

Regards

Can you try using the runtimeconfig app to change and save any values and see the values stick?

When I change some value in runtimeconfig app, this value is save. I can see this value in ddconfig. But tomcat restart clear my ddconfig, and ddconfig is empty.

Then the problem is with Tomcat if you haven't run any call after Tomcat is restarted.

Hi Wilson,

I will try to provide you more details.
Some Tomcat restarts results in having following lines in cataliana.out (not always, it is random behaviour):


INFO: Using path [/opt/AppServer/apache-tomcat-8.5.15/lib/ddconfig.xml] to configuration file
INFO: No runtimeconfigextensions.xml file found, skipping.
Error accessing [/opt/AppServer/apache-tomcat-8.5.15/lib/ddconfig.xml], using empty configuration file


Then, the ddconfig.xml is empty and we need to use ddadmin in order to configure it once again.

This has started to happen when we have moved from tomcat 6 to 8 and upgraded application to use the latest AAOD libraries.


I see very simmilar issue here, in this thread: https://www.devconnectprogram.com/forums/posts/list/20048.page.
Looking how Avaya has implemented this part of AAOD, I suppose the issue is with the class loader policy, which has changed beetwen Tomcat 6 and 8.

As you said, maybe it is related to the tomcat, but Avaya claims that AAOD is supporting Tomcat 8.


PS. The scertcommon library is only in the TOMCAT_HOME/lib directory.

We do support 8.0 and 8.5. That's what I am doing with you. The frustration is we've never seen this problem. We ran our tests on 8.5.23.