0

Version : jboss-eap-7.2.4

here's standalone.xml configuration part for logging, basically there's two size rotating file handler as the subhandler of the async handler.

 <subsystem xmlns="urn:jboss:domain:logging:6.0">
        <async-handler name="ASYNC">
            <queue-length value="8192"/>
            <overflow-action value="block"/>
            <subhandlers>
                <handler name="FILE"/>
                <handler name="MetricLogger"/>
            </subhandlers>
        </async-handler>

        <size-rotating-file-handler name="FILE" autoflush="true">
          <filter-spec value="not(match(&quot;application-metrics.*&quot;))"/>
          <formatter>
             <pattern-formatter pattern="%d{dd MMM yyyy HH:mm:ss,SSS} %5p [CMS] [%t] %C{1}.%M() - %m%n"/>
          </formatter>
          <file path="/opt/application/log/application.log"/>
          <rotate-size value="10m"/>
          <max-backup-index value="100"/>
          <append value="true"/>
       </size-rotating-file-handler>
       <size-rotating-file-handler name="MetricLogger" autoflush="true">
         <filter-spec value="all(match(&quot;application-metrics.*&quot;))"/>
        <formatter>
           <pattern-formatter pattern="%d{dd MMM yyyy HH:mm:ss,SSS} %5p [METRICS] - %m%n"/>
        </formatter>
        <file path="/opt/application/log/application-metrics.log"/>
        <rotate-size value="10m"/>
        <max-backup-index value="10"/>
        <append value="true"/>
      </size-rotating-file-handler>

it can run successfully at first and can print the log to the files ,but after running for a while ,it will throw below exception and the jboss will exit...

java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.rollback(AbstractPropertyConfiguration.java:244)
        at org.jboss.logmanager.config.LogContextConfigurationImpl.doForget(LogContextConfigurationImpl.java:355)
        at org.jboss.logmanager.config.LogContextConfigurationImpl.forget(LogContextConfigurationImpl.java:319)
        at org.jboss.as.logging.logmanager.ConfigurationPersistence.forget(ConfigurationPersistence.java:341)
        at org.jboss.as.logging.logmanager.ConfigurationPersistence.rollback(ConfigurationPersistence.java:349)
        at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler$1.handleResult(LoggingOperations.java:122)
        at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1533)
        at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1515)
        at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1472)
        at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1455)
        at org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1319)
        at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:876)
        at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
        at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
        at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:521)
        at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:470)
        at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:432)
        at org.jboss.as.server.ServerService.boot(ServerService.java:427)
        at org.jboss.as.server.ServerService.boot(ServerService.java:386)
        at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:372)
        at java.lang.Thread.run(Thread.java:748)
 
 Caused by: java.lang.NullPointerException: overflowAction is null
         at org.jboss.logmanager.handlers.AsyncHandler.setOverflowAction(AsyncHandler.java:117)
         ... 26 more No property "queueLength" type could be determined for handler "ASYNC"
Peter Yang
  • 11
  • 3
  • Valid values for overflow action are BLOCK or DISCARD, not sure if values are case sensitive... – areus Jan 21 '21 at 11:23
  • yeah, I have also tried upper case with the same result. – Peter Yang Jan 21 '21 at 13:02
  • That looks like it's coming after a reload. How did you configure the handler? – James R. Perkins Jan 21 '21 at 15:55
  • Thanks for the response! I add the configuration for the file handler in the post. when will reload happen? seems when the file was rotate , this error will probably happens – Peter Yang Jan 22 '21 at 04:52
  • The configuration looks fine. The file rotation shouldn't trigger a reconfiguration. The error looks like it's coming from the server boot. – James R. Perkins Jan 22 '21 at 23:21
  • thanks for the response! when this error happens ,the application deployed in the JBoss already started successfully and I can access the service from the browser. and it also can write log. so you mean at that moment the jboss server service may not finish booting? – Peter Yang Jan 22 '21 at 23:54

1 Answers1

0

We had the same issue in our team after upgrading to Wildfly 18 (we were many versions behind, hard to tell which version exactly caused it).

The solution for us was making sure the logging.properties file was properly generated based on our standalone.xml, since this is sort of the fallback logging configuration until the subsystem kicks in during startup.

The generation is in turn made when standalone.sh/bat is executed. We still have some open questions that remain:

  1. Why is this a requirement now? We never had the logging.properties file populated before.
  2. Exactly which step of the standalone.sh script triggers the generation of the logging.properties file. This is what we are currently evaluating to include into our custom startup process.