Hello, We are running Appian 7.6 and in one of our log files we have

Hello,

We are running Appian 7.6 and in one of our log files we have log entries of the type

[INFO ] 2015-07-20 08:41:19,388 - (ExpressionAggregatedDataCollector.java:recordTime:38) [gtag, Rule, 0]

These log entries take up close to 60% of the log file at an extremely high rate, meaning that the log file reaches its max size in less than a minute (close to 45 seconds).

I know that the class ExpressionAggregatedDataCollector is used to collect and log information regarding a set of expressions that are being evaluated, but is there a way to NOT have this log entry appear? I have been going through the appian_log4j.properties file and i can not find anything relevant.

Has anyone come across this in their own installation? Btw, we are running Appian on Websphere.

OriginalPostID-157432

OriginalPostID-157432

  Discussion posts and replies are publicly visible

  • Based on your support case you have the following lines in your appian_log4j.properties

    #log4j.logger.com.appian.perflogs.expressions-trace=INFO, EXPRESSIONS_TRACE

    #log4j.additivity.com.appian.perflogs.expressions-trace=false

    Perhaps you uncommented and/or modified these lines at any time previously and then commented them out again without first setting the value to OFF? Doing this would not turn off the logging.

    Assuming that this is the correct appian_log4j.properties file, i would suggest the following

    1. Uncomment the above two lines and save the file
    2. Wait a few minutes
    3. Change INFO to ERROR and save the file
    4. Wait a few minutes and then comment them out and save the file
    5. Check if the logging has stopped
  • @Abhi Thank you for your input, i will try this immediately. I would also like to ask if there is a more detailed documentation in the forum regarding these loggers and their properties. For example, i've seen that changing the INFO to ERROR in the sail-summary and/or sail-details loggers, then the perflog csv files were not being updated.
  • @Abhi Your input was very helpful as the extensive logging caused by this Trace appender has stopped and the system immediately became quite responsive.

    I would also like to ask about the following log entry which also appears at a very high rate.

    [INFO ] 2015-07-21 09:47:50,846 - (FeatureContext.java:log:375) begin com.appiancorp.common.query.TypedValueQueryValidator validate -> com.appiancorp.common.query.TypedValueQueryValidator getValue [Thread 412]

    Do you recognize this as another Trace appender?
  • That is also unnecessary trace logging. You can turn it off with something like:

    log4j.logger.feature_context=ERROR

    Given you're having these problems, though, I suspect you have globally changed the default log level from ERROR to INFO. That's going to cause a ton of unnecessary logging, so rather than individually turning off the worst offenders, I'd suggest you look at the differences between your appian_logj4.properties file and what is shipped with the product and revert any changes you aren't sure that you need.
  • I was able to stop the trace for FeatureContext by setting the logger log4j.logger.com.appiancorp.tempo.util.PerformanceLog to ERROR
  • These documentation links would be hepful to obtain information on the various types of logging in Appian -
    forum.appian.com/.../Logging.html
    forum.appian.com/.../Customizing_Application_Logging.html
  • Abhi, your input has been very helpful.
    However, i would like to ask you a couple more questions.

    1) You mentioned a global default log level setting. Is that something you can point me to because i have not been able to determine which one it is.

    2) In our UAT environment, i saw that the Trace logging was re enabled after the environment was restarted after having disabled it following the steps you mentioned in your first comment. My thought was that since those Trace appenders were commented out after having being disabled at runtime, they were re enabled when the environment was restarted. Is this case, possibly due to the global logging level setting?