Wildfly 11 randomly logs to console.log instead of server log

Question

Problem

Wildfly 11 randomly logs to console.log instead of the server.log file, although console log is not configured in the standalone.xml. This behaviour is reproducable at startup and sometimes happens in production mode, probably when there is extensive logging going on. This might be an important information, since the vast majority of log entries find their way to the server.log and only a few lines are logged to console log.

My first idea was, that Wildfly did not make the switch of the logging config from logging.properties to standalone.xml, yet at startup, when this happens. Due to the fact that this strange behaviour happens after successful deployment as well, the reason seems to be something else.

Log entries in the console.log cannot not be found in the server.log, so it looks like the files are exlusive, so one log entry is written to exactly one log file only. However, based on the logging categories all entries should be written to server.log.

Configuration

• Wildfly 11

• the urn:jboss:domain:logging:3.0 subsystem has no console-handler configured, only a periodic-rotating-file-handler

• the root logger is configured like this, so no console handler either

  <root-logger>
   <level name="INFO"/>
   <handlers>
       <handler name="FILE"/>
   </handlers>
  </root-logger>
  

• Over 20 war files deployed (I know, this is crazy, but it is a legacy software and not designed by me like that:-) )

Questions

Is there any logical reason for this behaviour? Is Wildfly using the console as fallback in exceptional cases, when it cannot write to the server.log? Do periodic-rotating-file-handlers have some kind of buffer size and if yes does it make sense to change that size? If yes, how can this size be changed?

I assume the large number of applications (wars) deployed cause the logging problem. Is there some resource (Threads/Thread pool etc) that can be exhausted in such a scenario?

I am thankful for any help I can get, so please share your ideas with me!

Answer 1

We identified the problem. After another analysis in turned out, that the log entries are not random and we could identify a component with a custom logging config.